Назад в ленту

Trunk Tools: как дообученный AI сократил проверку строительной документации с 60 дней до 10

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

Где проваливаются универсальные LLM на отраслевых данных

Фундаментальные языковые модели натренированы на широту, а не на глубину. «Универсальные LLM стараются быть хороши во всём, поэтому в любой нишевой задаче они слабы», — объясняет Крити Фаудждар, старший продакт-менеджер, работающий с AI-инфраструктурой и агентными системами. Редкие термины, отраслевая логика, негласный контекст, который любой практик «просто знает» — вот где они буксуют.

Разработчик Себастьен Де Больвье вторит: самый узкий бутылочный горлышко — это надёжность работы с данными, «перегруженными жаргоном, аббревиатурами и специфическими форматами». «Модель уровня GPT-4 может понять французский юридический контракт, но споткнётся на конкретных ссылках на статьи, которые обязан цитировать практик», — говорит он.

К тому же, добавляет Фаудждар, самые ценные корпоративные данные никогда не попадали в предобучение. Они сидят во внутренних системах и проприетарных форматах. «RAG помогает, но лишь даёт модели чуть более точные факты, хотя она всё равно не умеет нормально рассуждать в предметной области».

Критически важно дообучать модель на доменных данных, затем на хороших примерах задач и строить собственные системы оценки. «Несколько тысяч примеров от реальных практиков бьют миллионы наскрёбанных шумных», — уверена Фаудждар. Архитектура mixture-of-experts (MoE) даёт специализацию без взрывного роста затрат на инференс. А связка RAG с тонкой настройкой работает вдвойне: RAG подтягивает факты, а дообучение чинит словарь и рассуждения.

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

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

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

Восприятие, семантика, агенты: как устроен трёхуровневый стек Trunk

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

К тому же, скованные контекстным окном, вероятностные модели с трудом удерживают долгосрочную память проекта. «Я имею в виду не контекстное окно в несколько токенов, — уточняет Капур, — а память, растянутую на месяцы и годы, потому что именно столько длятся некоторые проекты».

Вместо этого трёхуровневая система Trunk разбивает workflow на:

  • Восприятие (чтение и извлечение данных из грязных документов: PDF, чертежи, сканы)
  • Семантический/графовый слой (осмысление данных и понимание их связей)
  • LLM и агенты сверху

Строительные чертежи — язык символов, объясняет Бюхнер. Дверь не всегда подписана «дверь»: иногда это просто дуга на стене, которую обученный глаз расшифровывает за годы практики. «Слой восприятия учит ИИ читать этот язык». Затем семантический слой наделяет информацию смыслом: связывает дверь с чертежом, где она детализирована, со спецификацией, которая её регламентирует, и с бригадой, которая её монтирует. Это помогает отвечать на ключевые вопросы инженеров: не «есть ли здесь дверь?», а «создаст ли эта дверь проблему в дальнейшем?».

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

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

Масштаб проблемы данных в строительстве

Строительные процессы «кишат неявными допущениями и связями между данными из множества источников», — говорит Бюхнер. А объём неструктурированных данных «человечески невозможно» обработать или осмыслить.

По оценке Бюхнер, средний высотный дом генерирует около 3,6 миллиона страниц документации. «Если распечатать их в стопку, она будет высотой с само здание».

Все три слоя стека Trunk — восприятие, семантика, LLM — обучаются на «очень специфических датасетах» от клиентов с «явного разрешения» и с авторазметкой/IP, объясняет Капур. Клиенты, не желающие, чтобы Trunk обучался на их данных, могут отказаться. Данные деидентифицируются и агрегируются; также Trunk собирает «гораздо больше» размеченных данных через другие каналы, например трёхмерные BIM-модели.

Trunk утверждает, что запускает только тех агентов, которые достигают точности около 95%. Команда поддерживает непрерывные пайплайны оценки на основе эталонных данных от клиентов и экспертов. Также используется модель «LLM как судья». «Это понятие — LLM как судья — нужно, чтобы оценить, насколько хорошо мы работаем, как субъективно, так и объективно», — поясняет Капур. Объективность может быть простым «правильно/неправильно», но субъективность требует нюансов. Например, при создании письма или описания модель-судья формирует составную оценку — числовое значение, агрегирующее разные метрики и проверяющее производительность или риск.

Проблемы есть, особенно с задержками, отмечает Бюхнер: как только увеличивается способность базовых моделей к рассуждению, растёт и риск латентности. Trunk поддерживает набор критериев оценки для объективного измерения задержек при любых изменениях инфраструктуры, агентов и API-вызовов. «Перед релизом клиентам мы убеждаемся, что заметные изменения пользовательского опыта стоят улучшений производительности», — говорит Бюхнер.

От 60 дней до 10: измеримая отдача

Платформа Trunk управляет семью ИИ-агентами, заточенными под строительство: анализ ответов на запросы информации (RFI), обзор смет, проверку чертежей и субмитталов. Агент по субмитталам, например, отслеживает отсутствующую, конфликтующую или несоответствующую информацию в спецификациях продуктов и RFI. Хотя это важнейший этап, «это ужасно нудный workflow», — признаётся Бюхнер, потому что человеку приходится сверять документы «с кучей других частей документов». Агент делает это за секунды, и Trunk утверждает, что сократил циклы субмитталов с 50–60 дней до 10, «что имеет огромные последствия для графика и финансов».

Сейчас Trunk дошёл до того, что агенты общаются напрямую друг с другом, и это «очень захватывающе», по словам Бюхнер. Например, один агент проверяет архитектурный чертёж на точность, а затем автономно передаёт его агенту, работающему с RFI, чтобы тот задал уточняющие вопросы. «Если в чертежах есть проблемы, агент RFI берёт управление и активно запрашивает разъяснения», — объясняет Бюхнер.

Клиенты Trunk сообщают об экономии от 20 до 40 минут на каждый полевой вопрос. Бюхнер отмечает, что работники на площадке лучше всех знают, сколько времени уходит на беготню из бытовок, копание в разбросанных проектных документах или распечатанных PDF, сверку расхождений и возврат для координации с подрядчиками. Дополнительные результаты от клиентов:

  • В среднем 8 минут экономии на поиск одного документа (проверка статуса, поиск локации, запрос количества).
  • В среднем 20 минут на стандартные перекрёстные ссылки (сверка 2–3 разделов спецификации для ответа).
  • В среднем 40 минут на многостраничное исследование (списки и фильтрация, сопоставление связей, анализ RFI и субмитталов по 4–6 документам).
  • В среднем 75 минут на сложные задачи (создание RFI и прочих коммуникаций, глубокая перекрёстная проверка документов, отслеживание изменений).

В одном случае агент проверки чертежей Trunk обнаружил, что конструкционная балка была сдвинута вверх на 8,5 дюймов. Архитектор это не задокументировал. Если бы изменение не поймали, проектный менеджер, скорее всего, был бы вынужден демонтировать и переустанавливать балку нужного размера. Переделка обошлась бы минимум в $10 000 плюс, разумеется, сдвинулись бы сроки.

Бюхнер привела и другие примеры: агент выявил завышение стоимости на $60 000 без обоснования субподрядчиком по ландшафту; определил, что камин нужно герметизировать до монтажа гипсокартона, что сэкономило около $100 000 на трудах, материалах и задержках; указал, что для электрической двери требуется панель, которая отсутствовала в электрических чертежах.

Уроки для других отраслей

Подход Trunk к созданию агентов применим в любой сфере, работающей с большими объёмами неструктурированных и отраслевых данных.

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

«Только тогда можно строить связи между точками данных, которые в конечном счёте питают агентные цепочки».

Поскольку в фундаментальные модели вкладываются огромные деньги, предприятиям стоит