La mayoría de las verticales no son bases de datos SaaS limpias y bien engrasadas; la realidad son documentos desagradables, esquemas propietarios, flujos de trabajo implícitos y tareas de larga duración con las que la mayoría de los modelos de propósito common tienen problemas.
Esto impulsó a la empresa de gestión de proyectos de construcción Trunk Instruments a crear una arquitectura especializada de tres capas (percepción, semántica, agentes) basada en datos muy detallados para respaldar una automatización industrial de alta precisión y relevancia.
Su pila especialmente diseñada ha reducido los ciclos de revisión de meses a días, ha evitado costosos errores de campo y ha brindado a los agentes autónomos la capacidad de razonar sobre millones de páginas de documentación, afirma Trunk.
«Realmente nos propusimos tomar los datos de sistemas dispersos, preprocesarlos, estructurarlos, pasar por nuestra ontología en un gráfico de conocimiento y luego entrenar modelos de IA», dijo Sarah Buchner, fundadora y directora ejecutiva de Trunk y ex carpintera.
Para los constructores de otros sectores verticales, el enfoque de Trunk podría servir como modelo para transformar el caos de datos en flujos de trabajo específicos de la industria y listos para agentes.
Dónde se descomponen los LLM de propósito common según los datos de la industria
Los LLM básicos, aunque potentes, están optimizados para su amplitud, no siempre su profundidad.
«Los LLM de propósito common están capacitados para funcionar bien en todo, por lo que son débiles en cualquier nicho», dijo Kriti Faujdar, gerente senior de productos que trabaja en infraestructura de inteligencia synthetic, inteligencia synthetic, seguridad y plataformas LLM. Por ejemplo: términos raros, razonamiento de dominio específico, el contexto tácito que cualquier profesional “simplemente conoce”.
Sébastien De Bollivier, desarrollador internet, de aplicaciones y de software program, estuvo de acuerdo en que el mayor cuello de botella es la confiabilidad de los datos que son “densos en jerga, con muchas abreviaturas y con un formato específico”.
«Un modelo de clase GPT-4 puede entender un contrato authorized francés, pero fallará en las referencias de artículos específicos que los profesionales deben citar», dijo.
Además, los datos empresariales más valiosos nunca llegaron a formar parte de la formación previa, señaló Faujdar. Está ubicado en sistemas internos y formatos propietarios. “RAG ayuda un poco”, dijo. «Pero simplemente está brindando mejores datos a un modelo que todavía no puede razonar adecuadamente en el dominio».
La formación previa sobre datos de dominio es basic; Luego, las empresas deberían perfeccionar los buenos ejemplos de tareas y crear sus propias evaluaciones. «Unos pocos miles de ejemplos de practicantes reales superan a millones de ejemplos raspados y ruidosos», dijo Faujdar.
La combinación de expertos (MoE) puede proporcionar especialización sin que se disparen los costos de inferencia. Emparejar RAG con ajustes finos también funciona bien; RAG maneja el largo camino factual mientras afina el vocabulario y el razonamiento.
De Bollivier señaló la ventaja de las pilas híbridas: un modelo de propósito common para razonamiento y orquestación, un modelo más pequeño y ajustado (o recuperación densa sobre un corpus curado) para extracción de dominio específico. Aconsejó: «No realice ajustes para hacer que el modelo sea ‘más inteligente’ en un dominio, ajústelo para hacerlo más confiable en el formato de salida específico que requiere su flujo de trabajo».
El comercio y la construcción son ciertamente industrias que están ganando terreno con estas técnicas, al igual que el sector jurídico y el de atención sanitaria, afirmó De Bollivier. Estas verticales tienen «muchos riesgos en cuanto a errores además de formatos de documentos estandarizados, lo que equivale a un claro retorno de la inversión en la capacitación del 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 (LLM) no son suficientes, 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 junto a un árbol.
Esto los hace insuficientes para una interpretación simbólica de alta precisión. Por ejemplo, en los 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, al estar limitados por los límites del contexto, los modelos probabilísticos luchan con la memoria de proyectos a largo plazo. «No me refiero a una ventana de contexto de unos pocos tokens», dijo Kapoor. «Estoy hablando de la memoria a largo plazo que se extiende a lo largo de meses y años, porque esa es la duración de algunos de estos proyectos».
En cambio, el sistema de tres capas de Trunk divide los flujos de trabajo en:
-
Percepción (lectura y extracción de datos de documentos desordenados como PDF, dibujos o escaneos)
-
Una capa semántica/gráfica (dar sentido a esos datos y comprender sus relaciones).
-
LLM y agentes en la cima.
Los planos de construcción suelen ser simbólicos, afirmó 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 gracias a años de práctica.
«La capa de percepción es lo que le enseña a la IA a leer ese idioma», dijo. La capa semántica luego le da significado a esa información; por ejemplo, relacionando la puerta con el dibujo que la detalla, la especificación que la rige y el comercio que la instala. Esto ayuda a responder las preguntas críticas de los ingenieros de proyectos: no «¿hay una puerta aquí?» pero «¿esta puerta crea un problema en el futuro?»
Particularmente en la construcción, ese cambio es importante porque el costo de un problema se agrava con el tiempo. «Un conflicto atrapado en el diseño tiene un costo relativamente bajo de abordar», dijo Buchner, «mientras que el mismo problema atrapado en el campo podría costar decenas de miles de dólares».
En un nivel alto, el sistema identifica el tipo de documento y comienza a extraer información basada en el contenido (dibujo, cronogramas, texto de párrafo). Luego, estos datos se “transforman y aumentan” en la plataforma, lo que desencadena flujos de trabajo agentes, como relaciones de gráficos de conocimiento y flujos de trabajo del usuario closing.
Por ejemplo, un agente podría revisar un boletín de arquitectura y producir una superposición visible que examine una versión anterior y una versión más nueva (marcando adiciones y eliminaciones), luego generar narrativas escritas que describan cuáles son esos cambios en términos simples. Esto ayuda a los usuarios a comprender qué ha cambiado y coordinar con los socios comerciales los precios actualizados y las órdenes de cambio.
La magnitud del problema de los datos en la construcción
Los flujos de trabajo de construcción están “repletos de suposiciones implícitas y conexiones entre datos en sus innumerables fuentes”, dijo Buchner. Y la cantidad de datos no estructurados es “humanamente imposible” de procesar o darle sentido.
Buchner estimó que un edificio alto genera en promedio 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 quieran recibir capacitación de Trunk sobre sus datos pueden optar por no participar.
Los datos se anonimizan y se agregan, y Trunk también recopila «toneladas más» de datos etiquetados a través de otros canales como el modelado de información de construcción (BIM) 3D.
Trunk cube que solo envía agentes que alcanzan alrededor del 95% de precisión. El equipo mantiene procesos de evaluación continua basados en datos reales de clientes y expertos. También emplean un modelo de LLM como juez.
«Esta noción de un LLM como juez es calificar qué tan bien lo estás haciendo, tanto subjetiva como objetivamente», dijo Kapoor. La objetividad puede ser un «correcto» o un «incorrecto» fácil, pero la subjetividad requiere más matices.
Por ejemplo, al crear un correo electrónico, una narrativa o una explicación, un LLM como marco de evaluación puede crear una puntuación compuesta o un valor numérico que agregue diferentes métricas y pruebe el rendimiento o el riesgo de un modelo.
Sin embargo, puede haber desafíos, particularmente con la latencia, señaló Buchner; Cada vez que aumenta la capacidad de razonamiento de los modelos subyacentes, también aumenta el riesgo de latencia. 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 API.
Luego, «antes de lanzarlo a los clientes, nos aseguramos de que los cambios marginales en la experiencia del usuario closing valga la pena por las mejoras de rendimiento», dijo Buchner.
De 60 días a ten: la recompensa medible
La plataforma de Trunk impulsa siete agentes de inteligencia synthetic diseñados específicamente para la construcción, como el análisis de respuestas a solicitudes de información (RFI), la revisión de ofertas o la revisión de dibujos y presentaciones.
El agente de envío, por ejemplo, señala información faltante, contradictoria o que no cumple con las especificaciones del producto y las RFI. Si bien es un paso esencial en el proceso de construcción, «es un flujo de trabajo muy molesto», dijo Buchner, porque los revisores humanos tienen que comparar documentos «con muchas otras partes de los documentos».
Pero el agente puede hacer esto en segundos y Trunk cube que ha reducido los ciclos de envío de 50 a 60 días a ten, «lo que tiene enormes implicaciones financieras y de cronograma».
Trunk se encuentra ahora en un lugar donde estos agentes se comunican directamente entre sí, lo cual es «bastante emocionante», dijo Buchner. Entonces, por ejemplo, un agente revisará la precisión de un dibujo arquitectónico y luego lo entregará de forma autónoma a los agentes que manejan las RFI y harán preguntas de seguimiento.
«Si los dibujos tienen problemas, el agente de RFI se hace cargo y pide activamente aclaraciones», explicó Buchner.
Trunk cube que sus clientes reportan ahorros de 20 a 40 minutos por pregunta de campo. Buchner dijo que los usuarios en el campo saben mejor que nadie lo «pérdida de tiempo» que es ir y venir de los trailers de la oficina, examinar documentos de proyectos en sistemas dispersos o archivos PDF impresos, conciliar discrepancias y regresar para coordinar con socios comerciales.
Trunk cube que sus clientes informan estos resultados adicionales:
-
Ahorro de tiempo promedio de 8 minutos para la recuperación de un solo documento (verificaciones de estado, búsquedas de ubicación, consultas de cantidad).
-
Ahorro de tiempo promedio de 20 minutos para las referencias estándar (referencias cruzadas de 2 a 3 secciones de especificaciones para formar una respuesta).
-
Ahorro de tiempo promedio de 40 minutos para la investigación de varios documentos (enumerar y filtrar consultas, mapear relaciones, analizar RFI y presentaciones de entre 4 y 6 documentos).
-
Ahorro de tiempo promedio de 75 minutos para tareas complejas (creación de RFI y otros materiales de comunicación, referencias cruzadas profundas entre documentos, seguimiento de cambios).
En un caso, el agente de revisión de planos de Trunk señaló que una viga estructural se había movido 8,5 pulgadas hacia arriba. Sin embargo, esto no fue documentado por el arquitecto. Si el cambio no se hubiera detectado, el director del proyecto probablemente habría tenido que quitar y reinstalar la viga del tamaño correcto, dijo Buchner. Esta reelaboración habría agregado $10,000 o más al presupuesto, y “ciertamente habría habido implicaciones en el cronograma”.
Buchner también señaló otros ejemplos: un agente señaló 60.000 dólares en precios exagerados sin justificación por parte de subcontratistas de jardinería; identificó una chimenea que debía sellarse antes de la instalación de paneles de yeso, lo que ahorró alrededor de $100 000 en mano de obra, materiales y demoras; y advirtió que una puerta eléctrica requería un panel que no estaba incluido en los planos eléctricos.
Aprendizajes para otras industrias
El enfoque de Trunk para la creación de agentes es aplicable a cualquier vertical que trabaje con grandes volúmenes de datos no estructurados y específicos de la industria. Los constructores que trabajan en sectores verticales específicos deben comprender los desafíos de datos específicos de la industria 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 comprender», dijo Buchner. «Solo entonces se podrán establecer conexiones entre los puntos de datos que, en última instancia, alimentarán los flujos de trabajo agentes». Se está invirtiendo mucho dinero en modelos fundamentales, 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, “construya su ventaja técnica donde los modelos genéricos no invierten y no funcionan bien”, dijo.
