Trunk Tools redujo la revisión de documentos de pila de 60 días a 10 al desechar modelos de propósito general.

La mayoría de los sectores no son bases de datos SaaS limpias y bien engrasadas; la realidad son documentos desordenados, esquemas propietarios, flujos de trabajo implícitos y tareas prolongadas con las que la mayoría de los modelos de propósito general luchan. Esto llevó a la empresa de gestión de proyectos de construcción Trunk Tools a construir una arquitectura especializada de tres capas —percepción, semántica, agentes— basada en datos altamente detallados para respaldar la automatización industrial de alta precisión y alta relevancia. Su pila diseñada a medida ha reducido los ciclos de revisión de meses a días, ha evitado costosos errores en campo y ha dado a los agentes autónomos la capacidad de razonar sobre millones de páginas de documentación, según Trunk. “Realmente nos propusimos tomar los datos de sistemas dispersos, preprocesarlos, estructurarlos, pasar por nuestra ontología hacia un grafo de conocimiento y luego entrenar modelos de IA”, dijo Sarah Buchner, fundadora y CEO de Trunk y ex carpintera. Para los constructores en otros sectores, el enfoque de Trunk podría servir como un modelo para transformar el caos de datos en flujos de trabajo específicos de la industria listos para agentes. Donde los LLM de propósito general fallan en los datos de la industria, los LLM de base, aunque potentes, están optimizados para la amplitud, no siempre para la profundidad. “Los LLM de propósito general están entrenados para estar bien en todo, así que son débiles en cualquier cosa de nicho”, dijo Kriti Faujdar, gerente de producto senior que trabaja en infraestructura de IA, IA agencial, seguridad y plataformas LLM. Por ejemplo: términos raros, razonamientos específicos del dominio, el contexto no verbal que cualquier profesional “simplemente sabe.” El desarrollador web, de aplicaciones y software Sébastien De Bollivier coincidió en que el mayor cuello de botella es la fiabilidad de datos que son “densos en jerga, cargados de abreviaturas y específicos de formato.” “Un modelo de clase GPT-4 puede entender un contrato legal francés, pero tendrá problemas con las referencias de artículos específicos que los profesionales necesitan citar”, dijo. Además, el dato más valioso de la empresa nunca llegó a la preentrenamiento, subrayó Faujdar. Está en sistemas internos y formatos propietarios. “RAG ayuda un poco”, dijo. “Pero solo está proporcionando mejores hechos a un modelo que aún no puede razonar adecuadamente en el dominio.” Es crítico el preentrenamiento en datos de dominio; las empresas deberían luego ajustar finamente con buenos ejemplos de tareas y construir sus propias evaluaciones. “Unas pocas miles de ejemplos de verdaderos profesionales superan a millones de datos extraídos ruidosos,” dijo Faujdar. La mezcla de expertos (MoE) puede proporcionar especialización sin que los costos de inferencia se disparen. Combinar RAG con ajuste fino también funciona bien; RAG maneja la larga trayectoria factual mientras que el ajuste fino corrige el vocabulario y el razonamiento. De Bollivier señaló la ventaja de las pilas híbridas: un modelo de propósito general para razonamiento y orquestación, un modelo más pequeño ajustado finamente (o recuperación densa sobre un corpus curado) para extracción específica del dominio. Aconsejó: “No ajustes finamente para hacer que el modelo sea 'más inteligente' sobre un dominio, ajusta finamente para hacerlo más fiable en el formato de salida específico que tu flujo de trabajo requiere.” Los oficios y la construcción son, sin duda, industrias que están viendo tracción con estas técnicas, al igual que el sector legal y de la salud, dijo De Bollivier. Estos sectores tienen “altas apuestas por errores más formatos de documentos estandarizados, lo que equivale a un claro ROI en entrenamiento de dominio.” Una advertencia honesta que vale la pena mencionar, dijo Faujdar: los modelos especializados a menudo pueden desmoronarse fuera de su dominio, por lo que a menudo no son útiles fuera de su experiencia (a menos que sean reentrenados). Percepción, semántica, agentes: dentro de la pila de tres capas de Trunk En dominios altamente especializados como la construcción, los "volcados de datos" en grandes modelos de lenguaje (LLMs) no sirven, dijo el CTO de Trunk, Amrish Kapoor. Esto se debe a que la mayoría de los transformadores son modelos probabilísticos: cuando se les da una imagen, informan que probablemente es un árbol, o probablemente un niño jugando al lado de un árbol. Esto los hace insuficientes para una interpretación simbólica de alta precisión. Por ejemplo, en documentos de construcción, un símbolo de 2 milímetros de ancho tiene un significado muy diferente según dónde se coloque. Además, limitados por los límites de contexto, los modelos probabilísticos luchan con la memoria de proyectos a largo plazo. “No me refiero a una ventana de contexto de algunos tokens”, dijo Kapoor. “Estoy hablando de memoria a largo plazo que se extiende a lo largo de meses y años, porque así de largos son algunos de estos proyectos.” En cambio, el sistema de tres capas de Trunk descompone los flujos de trabajo en: Percepción (leer y extraer datos de documentos desordenados como PDFs, dibujos o escaneos) Una capa semántica/grafica (dando sentido a esos datos y entendiendo sus relaciones). LLMs y agentes encima. Los dibujos de construcción son típicamente simbólicos, dijo Buchner. Una puerta no siempre está etiquetada como 'puerta.' A veces es simplemente un arco en una pared que un ojo entrenado aprende a leer con base en años de práctica. “La capa de percepción es lo que enseña a la IA a leer ese idioma”, dijo. La capa semántica luego da significado a esa información; por ejemplo, conectando la puerta al dibujo que la detalla, la especificación que la rige y el oficio que la instala. Esto ayuda a responder las preguntas críticas de los ingenieros de proyectos: No "¿hay una puerta aquí?" sino "¿esta puerta crea un problema más adelante?" Particularmente en construcción, ese cambio importa porque el costo de un problema se compone con el tiempo. “Un conflicto detectado en el diseño es relativamente de bajo costo de abordar,” dijo Buchner, “mientras que el mismo problema detectado en el campo podría costar decenas de miles de dólares.” A un alto nivel, el sistema identifica el tipo de documento y comienza a extraer información basada en el contenido (dibujo, cronogramas, texto de párrafo). Estos datos son luego “transformados y aumentados” en la plataforma, lo que desencadena flujos de trabajo agenciales como relaciones de grafo de conocimiento y flujos de trabajo para el usuario final. Por ejemplo, un agente podría revisar un boletín arquitectónico y producir una superposición visual comparando una versión anterior y una nueva (marcando adiciones y eliminaciones), luego generar narrativas escritas que describen qué son esos cambios en términos simples. Esto ayuda a los usuarios a entender qué ha cambiado y coordinarse con los socios comerciales sobre precios actualizados y órdenes de cambio. La magnitud del problema de datos en la construcción Los flujos de trabajo de construcción están “repletos de suposiciones e implicaciones implícitas y conexiones entre datos en sus variados orígenes,” dijo Buchner. Y la cantidad de datos no estructurados es “humanamente imposible” de procesar o dar sentido. Buchner estimó que un edificio de gran altura promedio genera alrededor de 3.6 millones de páginas de documentación correspondiente. “Si lo imprimes en una pila de papeles, sería tan alto como el edificio mismo.” Las tres capas de la pila de Trunk —percepción, semántica, LLM— están entrenadas en “conjuntos de datos muy específicos” de clientes con “permisos explícitos” y etiquetado automático/IP, explicó Kapoor. Los clientes que no desean que Trunk entrene en sus datos pueden optar por salir. Los datos están desidentificados y agregados, y Trunk también recoge “toneladas más” de datos etiquetados a través de otros canales, como la modelización de información de edificios en 3D (BIM). Trunk dice que solo envía agentes que logran alrededor del 95% de precisión. El equipo mantiene tuberías de evaluación continuas basadas en datos de verdad de clientes y expertos. También utilizan un modelo de LLMs como juez. “Esta noción de un LLM como juez es evaluar qué tan bien lo estás haciendo, tanto subjetiva como objetivamente”, dijo Kapoor. La objetividad puede ser un sencillo 'correcto' o 'incorrecto', pero la subjetividad requiere más matices. Por ejemplo, al crear un correo electrónico o narrativa o explicación, un marco de LLM como juez puede crear una puntuación compuesta, o un valor numérico que agrega diferentes métricas y evalúa el rendimiento o riesgo de un modelo. Puede haber desafíos, sin embargo, particularmente con la latencia, señaló Buchner; cada vez que se aumenta la capacidad de razonamiento de los modelos subyacentes, el riesgo de latencia también aumenta. Trunk mantiene un conjunto de criterios de evaluación para medir objetivamente la latencia cada vez que se realizan cambios en la infraestructura subyacente, los agentes y las llamadas de API. Luego, “antes de lanzar a los clientes, aseguramos que los cambios marginales en la experiencia del usuario final valgan la pena las mejoras de rendimiento,” dijo Buchner. De 60 días a 10: el retorno medible La plataforma de Trunk potencia siete agentes de IA diseñados específicamente para la construcción, como analizar respuestas a solicitudes de información (RFI), revisar ofertas o revisar dibujos y presentaciones. El agente de presentación, por ejemplo, marca información faltante, conflictiva o no conforme en las especificaciones de productos y RFIs. Aunque es un paso esencial en el proceso de construcción, “es un flujo de trabajo súper molesto,” dijo Buchner, porque los revisores humanos tienen que comparar documentos “con un montón de otras partes de documentos.” Pero el agente es capaz de hacer esto en segundos, y Trunk dice que ha reducido los ciclos de presentación de 50 a 60 días a 10, “lo que tiene enormes implicaciones en el calendario y las finanzas.” Trunk ahora está en un lugar donde estos agentes se están comunicando directamente entre sí, lo cual es “bastante emocionante,” dijo Buchner. Ya que, por ejemplo, un agente revisará un dibujo arquitectónico para verificar su precisión, y luego lo entregará de manera autónoma a los agentes que manejan RFIs y que hacen preguntas de seguimiento. “Si los dibujos tienen problemas, el agente de RFI se hace cargo y se comunica activamente para pedir aclaraciones,” explicó Buchner. Trunk dice que sus clientes informan ahorros de 20 a 40 minutos por cada pregunta de campo. Buchner dijo que los usuarios en el campo saben mejor que nadie cuánto tiempo se pierde al ir y venir de las oficinas, hurgar en documentos de proyectos en sistemas dispersos o en PDFs impresos, reconciliar discrepancias y coordinarse con socios comerciales. Trunk dice que sus clientes informan estos resultados adicionales: ahorro promedio de 8 minutos para la recuperación de un solo documento (chequeos de estado, búsquedas de ubicación, consultas de cantidades); ahorro promedio de 20 minutos para referencias estándar (referenciando entre 2 y 3 secciones de especificaciones para formar una respuesta); ahorro promedio de 40 minutos para investigación de múltiples documentos (listando y filtrando consultas, mapeando relaciones, analizando RFIs y presentaciones a través de 4 a 6 documentos); ahorro promedio de 75 minutos para tareas complejas (creando RFIs y otros materiales de comunicación, cruzando información entre documentos, seguimiento de cambios). En un caso, el agente de revisión de dibujos de Trunk marcó que una viga estructural se había movido 8.5 pulgadas. Sin embargo, esto no fue documentado por el arquitecto. Si no se hubiera detectado el cambio, es probable que el gerente del proyecto hubiera tenido que retirar e instalar la viga del tamaño correcto, dijo Buchner. Este retrabajo habría añadido $10,000 o más al presupuesto, y “ciertamente habría tenido implicaciones en el calendario.” Buchner también señaló otros ejemplos: un agente marcó $60,000 en precios exagerados sin justificación por parte de subcontratistas de paisajismo; identificó una chimenea que necesitaba ser sellada antes de la instalación de drywall, ahorrando alrededor de $100,000 en mano de obra, materiales y retrasos; y señaló que una puerta eléctrica requería un panel que no estaba incluido en los dibujos eléctricos. Aprendizajes para otras industrias El enfoque de Trunk para construir agentes es aplicable a cualquier sector que trabaje con grandes volúmenes de datos no estructurados y específicos de la industria. Los constructores que trabajan en sectores específicos deben entender los desafíos específicos de datos que enfrentan sus usuarios finales y construir una infraestructura técnica que pueda transformar datos no estructurados en algo que un “LLM pueda atravesar y entender,” dijo Buchner. “Solo entonces puedes construir las conexiones entre los puntos de datos que, en última instancia, alimentan flujos de trabajo agenciales.” Se está invirtiendo mucho dinero en modelos de base, por lo que las empresas deberían construir sistemas modulares que puedan aprovechar las fortalezas de varios modelos a medida que continúan mejorando, aconsejó Buchner. Luego, “construye tu ventaja técnica donde los modelos genéricos no están invirtiendo y no están funcionando bien,” dijo.