Рассвет стека суждений

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

Большинство компаний считают, что их «решения на базе ИИ» появятся в следующей версии Revit, Rhino, Vectorworks или Archicad. Достаточно подождать, установить обновление — и интеллектуальная помощь в проектировании станет ещё одной функцией программного обеспечения, которое они и так уже арендуют. Системы «Copilot» станут более функциональными, рутинные задачи исчезнут, а производительность будет неуклонно расти. Это вполне понятное предположение, но, на мой взгляд, оно ошибочно.

Поводом для написания этой статьи послужил проект с открытым исходным кодом от ALPA (AlpacaLabs LLC) — консалтинговой компании в области технологий проектирования, возглавляемой Федерико Негро. Проект под названием «Skills for Architects» является одной из самых наглядных публичных демонстраций того, как архитектурная компания может преобразовать свои знания в готовые к повторному использованию рабочие процессы на базе ИИ. На первый взгляд это выглядит как репозиторий GitHub, содержащий десятки навыков Claude. Но если присмотреться повнимательнее, становится ясно, что за этим стоит нечто гораздо большее. Это указывает на то, что следующим полем конкурентной борьбы в сфере ИИ для архитектуры, строительства и инжиниринга (AEC) станет вопрос о том, кому принадлежит интеллект, находящийся за пределами программного обеспечения BIM, а не о том, у кого в нем самые умные функции. Это значительно отличается от того, как большинство компаний в настоящее время воспринимают ИИ.

Сегодня практически каждый разговор вращается вокруг поставщиков программного обеспечения. Autodesk добавляет в Revit еще одного помощника. Graphisoft расширяет возможности ИИ в Archicad. Bentley представляет очередной Copilot. Поставщики соревнуются по функционалу, потому что именно этим компании-разработчики программного обеспечения занимались всегда. В этом нет ничего плохого, и на самом деле это неизбежно. ИИ становится еще одной функцией, которую ожидают увидеть в профессиональном программном обеспечении, точно так же, как ранее стали ожидаемыми рендеринг, обнаружение коллизий и совместная работа в облаке. Каждая крупная BIM-платформа будет продолжать внедрять всё больше интеллектуальных функций, и проектные организации должны обязательно этим воспользоваться. Ошибка заключается в том, чтобы считать, что это и есть конечная цель.

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

Более интересный вопрос заключается в том, где будет находиться настоящая интеллектуальная собственность, когда каждый поставщик начнёт предлагать полнофункциональный ИИ. Если каждая компания получит доступ к в целом схожим языковым моделям, а каждая BIM-платформа будет поставляться со своими собственными помощниками, откуда тогда будет браться конкурентное преимущество? Я полагаю, что ответ сводится к суждению — к тому, как компания интерпретирует и применяет тот ИИ, которым она пользуется.

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

Автоматизация против субъективного суждения

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

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

Именно это Дастин Шефер, руководитель отдела исследований компании Henderson Engineers, называет «стеком суждений» — совокупностью аргументов, которая делает одну проектную практику принципиально отличной от другой. Именно в этом сейчас и заключается конкурентное преимущество. Две компании могут использовать абсолютно одно и то же программное обеспечение BIM, одну и ту же модель искусственного интеллекта и одно и то же оборудование, но при этом создавать совершенно разные здания, поскольку на протяжении всего процесса проектирования они руководствуются разными суждениями.

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

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

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

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

Именно поэтому репозиторий ALPA «Skills for Architects» заслуживает внимания: он не просто демонстрирует очередной ИИ-помощник, а показывает, что экспертиза компании сама по себе может превратиться в программное обеспечение. В связи с этим возникает очевидный вопрос: как именно выглядит это программное обеспечение?

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

Что такое навык искусственного интеллекта?

ALPA заслуживает большой признательности, поскольку она сделала то, на что мало кто из организаций был готов. В то время как другие только говорят об ИИ, ALPA опубликовала рабочую эталонную архитектуру под открытой лицензией. Любой желающий может ознакомиться с ней, понять, как она работает, адаптировать её и развивать дальше. Благодаря этому «Skills for Architects» становится одним из наиболее наглядных общедоступных примеров, позволяющих объяснить, что на самом деле представляет собой «навык в области ИИ».

Этот репозиторий представляет собой сборник повторно используемых архитектурных знаний, организованных в модульную систему, которую компании могут расширять по мере развития собственного опыта. Если отбросить терминологию ИИ, то на самом деле ALPA опубликовала структуру для систематизации профессионального суждения.

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

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

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

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

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

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

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

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

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

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

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

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

Построение стека суждений

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

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

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

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

Именно здесь репозиторий ALPA становится особенно полезным. Это не столько готовое решение, сколько методология. Например, его «Навыки» по зонированию Нью-Йорка объединяют знания о местном планировании в форму, которую ИИ может последовательно применять. В этом подходе нет ничего уникально нью-йоркского. Та же самая схема могла бы в равной степени описывать политику «Зеленого пояса» Лондона, шотландские строительные стандарты, соответствие требованиям Части L или рекомендации в сфере здравоохранения в Австралии. Каждая компания уже обладает специализированными знаниями. Задача состоит в том, чтобы сделать их пригодными для повторного использования.

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

Именно здесь идея «неинтеллектуального» BIM-инструмента начинает обретать смысл. Скиллу не требуется от Revit, Rhino или Archicad ничего, кроме геометрии и метаданных, представленных в формате, который внешний агент может понять, обработать и, что особенно важно, в который он может записать результаты обратно. Интеллект начинает перемещаться из приложения для создания моделей в слой, принадлежащий самой архитектурной фирме.

Этот архитектурный сдвиг уже становится заметным. Данные модели теперь можно экспортировать в открытые столбцовые форматы, такие как Parquet, для проведения масштабных запросов. Сервисы геометрии, такие как Rhino Compute, предоставляют удаленный доступ к операциям моделирования. Серверы MCP становятся стандартным механизмом взаимодействия агентов искусственного интеллекта с программным обеспечением и внешними сервисами. Проблема уже не в том, может ли ИИ анализировать данные BIM. Проблема заключается в том, насколько чисто можно получить доступ к этой информации и насколько надежно можно записывать изменения обратно.

Запись данных, пожалуй, является более сложной задачей. Чтение BIM-модели относительно просто, но безопасное внесение в нее изменений с соблюдением ограничений, взаимосвязей и собственной модели данных приложения гораздо сложнее. Именно поэтому недавняя работа Open Design Alliance над серверами MCP имеет стратегическое значение. Предоставляя открытый программный доступ к проприетарным форматам проектирования, ODA дает компаниям возможность создавать рабочие процессы на базе ИИ, не привязанные к экосистеме одного конкретного поставщика.

Вопрос уже не в том, способен ли ИИ анализировать данные BIM. Вопрос в том, насколько беспрепятственно можно получить доступ к этой информации и насколько надежно можно сохранить внесенные изменения

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

Решите проблемы читаемости и записи результатов — и роль инструмента для создания BIM-моделей начнёт меняться. Он по-прежнему останется тем местом, где создаётся геометрия и координируется информация о проекте, поскольку эти возможности по-прежнему чрезвычайно ценны. С появлением движения «Autodrawings» вполне возможно, что этот процесс может быть частично автоматизирован и вынесен за пределы приложения. Все чаще монолит BIM становится лишь одним из компонентов гораздо более широкой экосистемы ИИ, причем интеллект, определяющий проект, находится вне приложения, закодирован в виде «навыков», управляется агентами и связан с собственной институциональной памятью компании. Это может оказаться самым важным архитектурным изменением, которое ИИ привносит в BIM. На протяжении десятилетий поставщики программного обеспечения владели как средой моделирования, так и большей частью связанного с ней интеллекта, а ИИ создает возможность разделить эти два компонента.

Институциональная память и чувство причастности

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

Именно поэтому так много крупных компаний вдруг заговорили о «озерах данных», «лейкхаусах» и платформах структурированных данных. Сама по себе лежащая в основе технология имеет почти второстепенное значение. На самом деле компании создают институциональную память. На протяжении многих лет компании вкладывали значительные средства в стандарты BIM, системы управления документацией и общие информационные среды (CDE), но эти системы были разработаны в первую очередь для хранения информации и обеспечения возможности её извлечения людьми. ИИ меняет это требование, поскольку теперь информация должна служить не только для извлечения людьми, но и для машинного рассуждения.

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

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

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

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

В отрасли это обычно называют «зависимостью от поставщика». Я всё чаще прихожу к выводу, что термин «плата за доступ к данным» является более подходящим, поскольку он лучше отражает коммерческую реальность. Плата за проезд подразумевает, что дорога принадлежит кому-то другому, кто-то другой устанавливает цену, а кто-то другой контролирует доступ. Тот же принцип действует, когда собственный экспертный опыт компании доступен только через платформу искусственного интеллекта другой компании. Вложив годы в накопление опыта в Skills и формирование институциональной памяти, компания может оказаться в ситуации, когда ей приходится платить каждый раз, когда запрашиваются эти знания. Независимо от того, является ли модель взимания платы токенами, вызовами API, лицензированием на основе использования или все более популярной концепцией ценообразования на основе результатов, эффект остается удивительно схожим. Компании рискуют неоднократно платить за доступ к интеллекту, который они создали сами.

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

Это различие имеет значение, поскольку базовые модели будут продолжать меняться. Claude будет совершенствоваться, GPT будет совершенствоваться, Gemini будет совершенствоваться, а модели с открытым исходным кодом станут более функциональными. Базовые технологии ИИ будут становиться всё более взаимозаменяемыми, но профессиональное суждение, лежащее в их основе, — нет. Навыки, системы управления, институциональная память и экспертиза, накопленные в ходе практической деятельности, являются уникальными активами. Их гораздо сложнее воспроизвести, чем очередную функцию ИИ, анонсированную в следующем выпуске программного обеспечения, и в конечном счёте именно их конкуренты не смогут просто «скачать».

Очевидные возражения

Подобный прогноз вызывает сопротивление, и возражения заслуживают серьезных ответов, а не простого отмахивания. Первое возражение — самое очевидное. Если навыки столь ценны, зачем компаниям их развивать, если Autodesk, Bentley, Graphisoft или Nemetschek просто предоставят их готовыми? Поставщики уже владеют платформой моделирования, интерфейсом, облачной инфраструктурой и отношениями с клиентами, и у них есть все стимулы для продвижения вверх по технологической цепочке. Ответ вытекает из ранее сделанного различия между автоматизацией и субъективным суждением. Программная компания может поставлять только то, что носит обобщенный характер, и в тот момент, когда она внедряет философию проектирования, методологию оказания медицинской помощи или подход к планированию одной конкретной компании, она рискует сделать продукт неподходящим для тысяч других клиентов. Общая автоматизация должна быть частью программного обеспечения, но конкурентное суждение, почти по определению, не может ею быть. С этим связанное возражение касается данных. Autodesk хранит миллионы моделей Revit и, несомненно, накопила больше архитектурных знаний, чем любая отдельная компания. Она, безусловно, накопила больше геометрических данных. Но у неё нет логики, лежащей в основе этих моделей, технических заданий, ограничений, аргументов, обсуждавшихся на проектных совещаниях, и альтернативных решений, которые рассматривались и отвергались. Конкурентным преимуществом является именно то мышление, которое породило эту геометрию.

Второе возражение носит культурный характер. Архитекторы проектируют здания, и у большинства из них нет ни желания становиться ИТ-компаниями, обслуживающими системы искусственного интеллекта, ни ресурсов, чтобы даже попытаться это сделать. Наверняка только такие компании, как Foster + Partners, Perkins&Will, Gensler или Arup, могут себе это позволить? Два года назад это возражение было вполне обоснованным, но сейчас этот барьер быстро рушится. Репозиторий ALPA является открытым исходным кодом, навыки в основном представлены в виде простого текста, а MCP перешел из стадии эксперимента в статус стандарта. Написание хорошего «Skill» теперь больше похоже на разработку офисного стандарта, чем на заказ приложения, и по-настоящему сложная часть заключается вовсе не в программировании. Она заключается в том, чтобы убедить руководство четко сформулировать, как на самом деле работает бюро — это проблема управления знаниями, с которой архитектура сталкивается уже целое столетие, а не новая техническая задача.

Если каждая компания имеет доступ к примерно одинаковым языковым моделям, а каждая BIM-платформа поставляется со своими собственными помощниками, то откуда же берется конкурентное преимущество?

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

Кроме того, существует прагматическое возражение: большинство архитектурных бюро ничего не разрабатывают самостоятельно, а просто пользуются тем, что предлагает их поставщик. Это почти наверняка так, и это не является критикой. Сегодня большинство бюро также не разрабатывают собственное программное обеспечение, однако то меньшинство, которое этим занимается — такие компании, как HOK, ZHA, Buro Happold или Foster + Partners, — неизменно демонстрируют результаты, превосходящие их возможности. Конкурентное преимущество никогда не требовало повсеместного внедрения. Оно требует, чтобы некоторые компании делали что-то ценное, чего не делают другие, и если навыки в конечном итоге будут продаваться на торговых площадках, то общие навыки превратятся в обычный товар, в то время как те, что основаны на собственном опыте компании в реализации проектов, отношениях с клиентами и философии проектирования, останутся именно тем, что ни одна торговая площадка не сможет продать.

Последнее возражение — то, которое я слышу реже всего, но нахожу наиболее интересным. А что, если базовые модели просто станут достаточно хорошими? Если будущий «Claude» или GPT сможет рассуждать как старший архитектор, возможно, весь уровень «Skills» станет ненужной «подпоркой». Я бы утверждал, что из этого следует противоположный вывод. Базовые модели обеспечивают общий интеллект, но профессиональная практика опирается на контекст: конкретного клиента, конкретную склонность к риску, конкретные полномочия по планированию, конкретные внутренние стандарты, конкретный с трудом извлеченный урок из неудачного проекта. Чем лучше становится общая модель, тем в большей степени именно эти факторы становятся единственными оставшимися отличительными чертами, поскольку у всех остальных есть доступ к одному и тому же общему интеллекту. Лучшие модели не только не делают знания, специфичные для конкретной практики, излишними, но и превращают их в саму суть дела.

Заключение

Было бы ошибкой рассматривать это как аргумент против Autodesk, Bentley, Graphisoft, McNeel или любого другого поставщика BIM-решений или геометрических инструментов. Эти компании будут и дальше предлагать всё более совершенные ИИ-решения, и проектные организации должны этим воспользоваться. Автоматизация, появляющаяся в приложениях для проектирования, избавит от рутинной работы, повысит согласованность и станет неотъемлемой частью любой проектной платформы. Это первый уровень ИИ, и он станет обязательным условием.

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

Третий этап только начинает проступать. По мере того как «Skills» связываются с институциональной памятью, архитектурные бюро выходят за рамки автоматизации отдельных задач и переходят к системам ИИ, способным рассуждать на основе собственных проектов, стандартов и опыта. На этом этапе конкурентное преимущество будет заключаться в профессиональном суждении, лежащем в основе модели, поскольку у всех будет доступ к одним и тем же базовым моделям. С этой точки зрения направление развития отрасли начинает выглядеть иначе.