Как я сделал AiRevit: от обычного текста до BIM-модели в Revit б без LLM

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

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

Я решил собрать свой вариант и назвал его AiRevit. Это не чатик с LLM поверх Revit. Тут вообще не предполагается использования такой архитектуры, которая бы основывалась на угадывании токена (нам не нужно ничего угадывать, нужно соблюдать строгие строительные правила). Это детерминированный pipeline, где текст сначала превращается в структурированный program_graph, потом в layout_solution, а уже потом в реальные элементы Revit через Dynamo и Python-скрипты. В репозитории это разложено на Node 3, Node 4 и Node 5, чтобы не было каши и чтобы каждый кусок отвечал за свою часть работы. (https://github.com/Rearks/AiRevit)

Что вообще делает AiRevit

Если по-простому, пользователь пишет нормальным человеческим языком, что он хочет получить. Например, офис с двумя кабинетами, общей площадью, коридором и санузлом. Дальше система запарсивает промт в JSON, проверяет ограничения и ведет это все по понятному сценарию. В итоге в Revit появляются стены, двери и помещения. Без всяких лишних галлюцинаций! Такой подход у проекта прямо заявлен как deterministic, data-driven pipeline без LLM и без cloud-зависимостей.

И вот тут важная мысль: AI в названии проекта тут скорее про направление и про перспективу, а не про то, что внутри сидит LLM и рулит моделью. По факту проект сейчас держится на правилах, словарях, графе и генераторе раскладки. Это на удивление приземленно, и именно поэтому оно мне нравится.

Как устроен пайплайн

В репозитории пайплайн собран в Dynamo-цепочку. Node 2 дает путь к папке с проектом, Node 3 превращает текстовый промт в program_graph, Node 4 берет этот граф и строит layout_solution, Node 5 уже создаёт элементы в Revit. В dynamo_pipeline.md это расписано именно как последовательность из Python Script узлов, а запуск ожидается прямо из Dynamo внутри Revit.

Архитектура проекта такая:

1. нормализация входного текста,

2. распознавание типа здания,

3. разбор помещений и количеств,

4. проверка обязательных пространств,

5. извлечение ограничений,

6. сборка графа,

7. генерация планировки,

8. создание BIM-элементов.

Для строительного проекта на мой взгляд оптимально.

Что делает prompt_to_program_graph.py

Вот здесь начинается самое вкусное. Файл prompt_to_program_graph.py у меня бы назвал сердцем первого этапа. Он берет словарь, нормализует текст и раскладывает промт на структурные куски. В коде видно, что входной текст приводится к нижнему регистру, схлопываются пробелы, потом загружается словарь vocabulary

Дальше идет нормальный pipeline:

• detect_building_type понимает, что за тип объекта перед нами,

• detect_quantities вытаскивает количества помещений,

• ensure_required_spaces добавляет обязательные помещения, если они не были явно указаны,

• detect_ratio ловит соотношения площадей,

• detect_constraints собирает дополнительные ограничения,

• затем строятся spaces, connections, constraints, flows

Мне в этом нравится именно то, что смысл промта довольно быстро превращается в граф. Это уже структурированная модель задачи. Внутри program_graph у проекта есть version, schema_type, graph_id, блок source с оригинальным промтом и блок metadata с типом здания. Для сохранения используется файл вида prompt_{graph_id}.json.

Отдельно отмечу одну важную штуку. В vocabulary.json у проекта лежит словарь с синонимами для типов помещений. Например, санузел может матчиться как wc, toilet, restroom, bathroom, washroom и так далее. Это выглядит просто, но на практике именно такие вещи делают систему живой. Пользователь пишет по-своему и генератор все равно понимает, что имелось в виду, без использования языковых моделей где часто возникают галлюцинации.

Что делает layout_generator_v2.py

После того как program_graph собран, его подхватывает генератор раскладки. И вот тут начинается уже геометрия и score-based перебор. По коду видно, что генератор строит layout, считает score, собирает warnings и считает метрики вроде общей площади, числа комнат и числа openings. Потом это все упаковывается в layout_solution с boundary, rooms и openings.

program_graph отвечает на вопрос “что вообще нужно построить”, а layout_solution уже отвечает на вопрос “как это можно разложить на плоскости так, чтобы оно хотя бы выглядело адекватно”. В коде есть score_layout, есть генерация кандидатов и выбор лучшего варианта через generate_best_layout. У layout есть метрики. Тут нет никакого элемента угадывания.

Еще один плюс архитектуры в том, что правила живут в данных. Можно добавлять новые типы помещений через vocabulary.json и space_types.json, а еще докидывать размеченные файлы в dataset/program_graphs/ без изменений в core nodes. Со временем, я надеюсь, у нас будут dataset под ресторан, квартиру, больницу и другие типы объектов.

Почему я вообще не стал применять LLM

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

Так что здесь логика такая: сначала структура, потом ограничения, потом уже геометрия и только потом Revit. Это скучнее, чем магия, зато работает. И в строительстве это именно то что нужно.

Масштабируемость

Самая интересная часть лично для меня начинается там, где проект перестает быть просто генератором и становится сборщиком датасета. Сейчас каждый program_graph.json и каждая раскладка уже несут в себе структурную информацию: какие были помещения, какие связи между ними, какие ограничения сработали, какой layout получил score, где генератор ругнулся warning’ами. То есть мы не просто строим BIM-модель, а копим обучающий след.

Вот здесь и всплывает тема графовой нейросети GNN. Если накопится хотя бы тысяча нормальных JSON-ов, уже можно думать о своей GNN, которая будет учиться на графе помещений, связях и ограничениях. Чтобы со временем заменить часть эвристик на модель, которая умеет предсказывать более удачные adjacency patterns, относительное расположение помещений и, возможно, стартовую раскладку. Это уже research-to-product путь, вовсе не тоже самое что “давайте прикрутим нейросеть, потому что модно”.

Конечно, тысяча JSON-ов сама по себе еще не делает чудо. Без внятной разметки, единых схем, качества данных и валидации GNN магию нам не сотворит. Так что GNN здесь скорее следующий слой над текущей rule-based логикой.

Что особенно приятно в текущей архитектуре

Мне самому в этом проекте нравится несколько вещей.

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

Во-вторых, все этапы можно отдельно дебажить. Если криво сгенерился program_graph, не надо сразу лазить в Revit. Если сломалась раскладка, это зона layout_generator_v2. Если итоговые элементы в модели вышли не так, тогда уже копаешь Node 5. Такая декомпозиция экономит кучу нервов.

В-третьих, проект хорошо ложится в open source формат. В README прямо есть путь для контрибьюторов: валидировать файлы, отправлять PR в dataset/program_graphs/, указывать тип здания, число файлов, список space types и источник данных.

Что дальше

Следующий логичный шаг я вижу так:

• собирать больше размеченных program_graph.json,

• добавлять новые типы пространств и домены,

• улучшать scoring в layout generator,

• и уже потом пробовать GNN как отдельный слой поверх текущей логики.

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

Вместо вывода

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