A Building as a Repository: KIR, a Typed Intermediate Representation for Agent-Authored Building Information Models
Este artigo introduz o KIR, uma representação intermediária tipada que trata modelos de informação da construção como programas versionados para detectar e representar sistematicamente sete modos de falha específicos em construções autoria de agentes autônomos, demonstrando melhorias significativas no diagnóstico de erros e na compactação de código em comparação com a manipulação direta da API do hospedeiro.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine um mundo onde as plantas de nossas cidades não são apenas desenhos estáticos, mas instruções vivas escritas por agentes de software inteligentes. Esses agentes são projetados para construir modelos digitais de edifícios, camada por camada, cômodo por cômodo, usando softwares complexos nos quais arquitetos e engenheiros confiam todos os dias. O desafio é que esses programas de software foram construídos para mãos humanas, não para máquinas autônomas. Eles reagem a comandos de formas que são frequentemente imprevisíveis: uma ferramenta pode falhar silenciosamente, uma escolha pode ser feita sem um registro do porquê, ou uma peça crítica de informação pode desaparecer sem deixar rastros. Quando um arquiteto humano comete um erro, ele consegue ver o erro, entender o contexto e corrigi-lo. Quando um agente de software comete um erro nesse ambiente, ele frequentemente não consegue dizer o que deu errado, o que estava tentando fazer ou se o edifício que criou realmente corresponde ao design que lhe foi dado. O resultado é um sistema onde o computador pode afirmar que um trabalho está concluído, mesmo que o edifício produzido seja falho ou incompleto.
Este é o problema que um pesquisador chamado Dmitry Kuklev se propôs a resolver. Ele fez uma pergunta simples, mas profunda: e se parássemos de pedir a esses agentes que escrevessem o código bruto que fala diretamente com o software de construção e, em vez disso, pedíssemos que escrevessem um plano claro e tipado que um compilador pudesse verificar antes que qualquer coisa fosse construída? O resultado é um novo sistema chamado KIR. Ele trata um edifício não como uma coleção de arquivos, mas como um programa mantido em um repositório versionado, muito parecido com uma biblioteca de instruções que pode ser lida, verificada e revisada. A ideia central é que, antes de um agente tentar construir uma parede ou posicionar uma porta, ele deve primeiro escrever exatamente o que pretende fazer, e um sistema separado deve verificar se o plano é sólido, se as referências são claras e se as consequências são conhecidas. Se o plano for ambíguo, o sistema recusa-se a prosseguir e explica exatamente o porquê, oferecendo uma lista de possíveis correções. Essa abordagem desloca o fardo de adivinhar e esperar para saber e verificar.
Os pesquisadores construíram este sistema para lidar com sete maneiras específicas pelas quais um projeto de construção pode dar errado sem que ninguém perceba. No modo antigo de fazer as coisas, um agente poderia tentar selecionar um nível de andar específico, mas se dois níveis tiverem nomes semelhantes, o software pode simplesmente escolher o primeiro que encontrar e seguir em frente, deixando o agente inconsciente de que escolheu o errado. No novo sistema, essa ambiguidade é detectada imediatamente. O sistema interrompe o processo e apresenta um registro de recusa que lista o problema exato e os candidatos disponíveis, forçando o agente a fazer uma escolha deliberada. Da mesma forma, se um agente deixar um valor em branco, esperando que o software o preencha com um padrão, o novo sistema registra exatamente de onde veio esse padrão. Ele mantém um log permanente de se um valor foi escrito pelo agente, calculado por uma macro ou fornecido pelo próprio software. Isso cria um rastro de proveniência, um histórico de cada decisão tomada na construção do modelo.
Para testar essa ideia, os pesquisadores criaram um ambiente controlado onde poderiam realizar experimentos sem a necessidade de o software de construção real estar em execução. Eles construíram um compilador que recebe o plano tipado do agente e o verifica contra uma captura (snapshot) de um modelo de edifício. Em um experimento, eles alimentaram o sistema com quarenta e dois programas diferentes, alguns dos quais continham erros deliberados projetados para quebrar o sistema. O sistema recusou com sucesso vinte e nove desses programas falhos, fornecendo códigos de diagnóstico detalhados que explicavam exatamente o que estava errado. Crucialmente, ele fez isso sem travar ou lançar um erro não capturado; ele simplesmente parou e explicou o problema. Para os programas que foram aceitos, o sistema gerou uma quantidade massiva de código para rodar no software de construção real. Um único design de edifício que levava cem linhas de instruções para ser descrito no novo sistema expandiu-se para quase quatro milhões de caracteres de código quando traduzido para o software hospedeiro. Essa diferença massiva destaca a complexidade do software subjacente e o valor de ter um plano compacto e legível por humanos que se situa entre o agente e a máquina.
O sistema também introduziu uma nova forma de pensar sobre o estado de um projeto de construção. Nos sistemas tradicionais, uma transação é ou bem-sucedida ou falha. Neste novo sistema, existe um terceiro estado: não confirmado. Se o software enviar um comando para construir uma parede, mas a resposta for perdida ou incerta, o sistema não adivinha se funcionou. Em vez disso, marca a ação como não confirmada e exige uma etapa de verificação específica antes que ela possa ser tentada novamente. Isso evita que o sistema assuma que um elemento do edifício existe quando ele pode não existir. Os pesquisadores também construíram um "caminho reverso", uma maneira de ler um modelo de edifício finalizado de volta para a linguagem do sistema. Esse processo verifica se cada elemento no modelo pode ser contabilizado. Se o sistema encontrar uma parte do edifício que não consegue entender ou expressar, ele não a descarta silenciosamente; ele a registra como um "átomo" com um motivo específico para a falha, garantindo que nenhuma parte do edifício seja perdida na tradução.
A avaliação deste sistema foi rigorosa. Os pesquisadores testaram o sistema em uma torre simulada de sessenta andares, uma estrutura complexa com centenas de andares e milhares de colunas. Eles descobriram que o sistema podia gerar todo o plano do edifício em um formato compacto de pouco mais de onze mil caracteres, que depois se expandia para o código necessário para o software hospedeiro. Eles também testaram a capacidade do sistema de lidar com conflitos quando múltiplos agentes tentam editar o mesmo edifício. O sistema utiliza um método chamado "compare-and-swap", que garante que, se dois agentes tentarem alterar a mesma parte do edifício ao mesmo tempo, o sistema detecte o conflito e recuse a fusão das alterações até que os agentes resolvam o desacordo. Isso evita o tipo de corrupção de dados que acontece frequentemente quando várias pessoas trabalham no mesmo arquivo digital.
No entanto, os pesquisadores são cuidadosos ao declarar o que ainda não provaram. Embora o sistema funcione perfeitamente em seus testes offline e gere código que compila com sucesso, eles ainda não realizaram uma comparação controlada para ver se agentes usando este novo sistema são melhores em construir coisas do que agentes que escrevem código diretamente. Esse experimento está planejado, mas ainda não foi feito. Os resultados atuais mostram que o sistema é robusto, que ele detecta erros que passariam despercebidos e que fornece um registro claro e inspecionável de cada decisão tomada. Ele separa a validade do plano do sucesso da execução e da correção do design final, tratando-os como três coisas distintas que devem ser verificadas separadamente.
A significância deste trabalho reside na sua mudança de um modelo de execução cega para um de construção baseada em evidências. Ao tratar o edifício como um programa que pode ser lido, verificado e revisado, o sistema dá aos agentes autônomos a capacidade de raciocinar sobre suas próprias ações. Ele fornece um vocabulário para a falha, permitindo que o sistema diga "eu não posso fazer isso porque X" em vez de apenas falhar silenciosamente. Essa abordagem não torna apenas o software mais confiável; ela torna o processo de construção com agentes transparente e responsável. Os pesquisadores mostraram que é possível construir um sistema onde o computador saiba o que está fazendo, por que está fazendo e o que alcançou, criando uma base para um futuro onde agentes inteligentes possam colaborar com humanos para projetar e construir as estruturas complexas do nosso mundo. O trabalho serve como uma demonstração de que, com as ferramentas certas, o hiato entre a intenção de um agente e o resultado final pode ser preenchido com clareza e precisão.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.