Trunk Tools отказывается от универсальных моделей

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

Это побудило компанию по управлению строительными проектами Trunk Tools создать специализированную трехуровневую архитектуру (восприятие, семантика, агенты), основанную на высокодетализированных данных, для поддержки высокоточной и актуальной отраслевой автоматизации.

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

«Мы действительно поставили перед собой задачу собрать данные из разрозненных систем, предварительно обработать их, структурировать, пропустить через нашу онтологию в граф знаний, а затем обучить модели искусственного интеллекта», — рассказала Сара Бухнер, основатель и генеральный директор Trunk Tools и в прошлом плотник.

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

Где универсальные языковые модели дают сбой на отраслевых данных

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

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

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

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

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

Предварительное обучение на доменных данных имеет критически важное значение; затем предприятия должны выполнить дообучение (fine-tuning) на примерах качественных задач и создать собственные методы оценки. «Несколько тысяч примеров от практикующих специалистов превосходят миллионы заскрейпленных и зашумленных данных», — считает Фоудар.

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

Де Болливье указал на преимущества гибридных стеков: универсальная модель для рассуждений и оркестровки, меньшая дообученная модель (или плотный поиск по курируемому корпусу) для доменно-специфичного извлечения. Он посоветовал: «Не дообучайте модель, чтобы сделать ее „умнее“ в какой-то предметной области — дообучайте ее, чтобы сделать более надежной в отношении конкретного формата вывода, которого требует ваш рабочий процесс».

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

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

Восприятие, семантика, агенты: заглядываем внутрь трехуровневого стека Trunk Tools

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

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

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

Вместо этого трехуровневая система компании разделяет рабочие процессы на следующие составляющие:

• Восприятие (чтение и извлечение данных из несовершенных документов, таких как PDF-файлы, чертежи или сканы).

• Семантический / граф-слой (осмысление этих данных и понимание связей между ними).

• Языковые модели и агенты поверх них.

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

«Уровень восприятия — это то, что учит ИИ читать этот язык», — сказала она. Семантический слой затем придает этой информации смысл; например, связывает дверь с чертежом, в котором она детализируется, спецификацией, которая ее регламентирует, и подрядчиком, который ее устанавливает. Это помогает ответить на важнейшие вопросы инженеров-проектировщиков: не «есть ли здесь дверь?», а «создаст ли эта дверь проблемы в дальнейшем?»

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

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

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

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

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

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

Все три слоя стека Trunk Tools — восприятие, семантика, LLM — обучены на «очень специфических наборах данных» от клиентов с «явными разрешениями», авторазметкой и защитой интеллектуальной собственности, пояснил Капур. Клиенты, которые не хотят, чтобы Trunk обучала системы на их данных, могут отказаться.

Данные обезличиваются и агрегируются, а Trunk Tools также собирает «гораздо больше» размеченных данных через другие каналы, такие как трехмерное информационное моделирование зданий (BIM).

Компания заявляет, что выпускает только тех агентов, которые достигают точности около 95%. Команда поддерживает конвейеры непрерывной оценки на основе данных о реальном положении дел (ground truth), полученных от клиентов и экспертов. Они также используют модель «LLM в качестве судьи» (LLMs-as-a-judge).

«Концепция использования LLM в качестве судьи заключается в оценке того, насколько хорошо вы справляетесь с задачей, как субъективно, так и объективно», — сказал Капур. Объективность может быть простой («правильно» или «неправильно»), но субъективность требует большего внимания к нюансам.

Например, при создании электронного письма, описания или пояснения структура «LLM в качестве судьи» может сформировать совокупный балл или числовое значение, которое объединяет различные метрики и тестирует производительность или риски модели.

Тем не менее, могут возникать трудности, особенно с задержкой (латентностью), отметила Бухнер: всякий раз, когда возможности базовых моделей по рассуждению возрастают, риск увеличения задержки также растет. Trunk Tools поддерживает набор критериев оценки для объективного измерения латентности всякий раз, когда вносятся изменения в базовую инфраструктуру, агентов и вызовы API.

Затем, «прежде чем выпустить продукт для клиентов, мы убеждаемся, что незначительные изменения в пользовательском опыте полностью оправданы улучшением производительности», — добавила Бухнер.

От 60 дней до 10: измеримая окупаемость

Платформа Trunk Tools поддерживает семь ИИ-агентов, специально созданных для строительства, таких как анализ ответов на запросы информации (RFI), обзор тендеров или проверка чертежей и исполнительной документации.

Агент по работе со сдаточной документацией (submittals), например, выявляет отсутствующую, противоречащую или не соответствующую требованиям информацию в спецификациях продуктов и RFI. Хотя это важный этап строительного процесса, «это ужасно раздражающий рабочий процесс», сказала Бухнер, потому что рецензентам-людям приходится сравнивать документы «с кучей других частей документов».

Но этот агент способен справиться с задачей за считанные секунды, и, по заявлению Trunk Tools, он сократил циклы рассмотрения документации с 50–60 дней до 10, «что имеет огромное значение для графиков и финансов».

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

«Если в чертежах есть проблемы, агент по RFI берет инициативу на себя и активно запрашивает разъяснения», — пояснила она.

В Trunk Tools заявляют, что клиенты сообщают об экономии от 20 до 40 минут на один вопрос с площадки. По словам Бухнер, пользователи «в полях» лучше кого бы то ни было знают, какой это «поглотитель времени» — бегать туда-сюда из строительных вагончиков, копаться в проектной документации в разрозненных системах или печатных PDF-файлах, устранять несоответствия и возвращаться для координации с партнерами по смежным работам.

Компания заявляет, что ее клиенты сообщают о следующих дополнительных результатах:

• В среднем 8 минут экономии времени на поиск по одному документу (проверка статуса, поиск местоположения, запросы о количестве).

• В среднем 20 минут экономии времени на стандартное обращение к источникам (перекрестная проверка 2–3 разделов спецификаций для формирования ответа).

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

• В среднем 75 минут экономии времени на выполнение сложных задач (создание RFI и других коммуникационных материалов, глубокая перекрестная проверка по документам, отслеживание изменений).

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

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

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

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

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

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

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

Затем «стройте свое техническое преимущество там, где общие модели не инвестируют средства и показывают плохие результаты», заключила она.