Um LLM não é um solver

Por que isto importa

Produtos de chat colapsam quatro afirmações distintas numa frase: «o período é 0.42 s». Essa frase pode ser um cálculo determinístico, uma sugestão de IA, um juízo humano ou um resultado validado. Não são intercambiáveis. Misturá-los é como texto não verificado acaba em pacotes de cálculo.

Este site trata programação e IA como ferramentas para problemas de engenharia, não como autoridades. Um modelo de linguagem pode ajudar você a escrever, buscar e redigir. Não substitui um solver, uma norma nem o engenheiro que assina.

Quatro papéis que a linguagem de marketing achata

Mantenha esses papéis separados em cada fluxo, inclusive nos que nunca abrem uma janela de chat.

Cálculo determinístico. Mesmos insumos documentados, mesmo algoritmo, mesmas saídas. O caminho é inspecionável: uma derivação, uma planilha travada, um modelo OpenSees escrito, uma expressão publicada em forma fechada. Se você não consegue repetir, não é este papel.

Sugestão de IA. Geração de tokens condicionada a um prompt e a dados de treino. O texto pode parecer Tcl, Python ou um número de cláusula. Parecer engenharia não é executar engenharia. Amostragem, limites de contexto e dados de projeto faltando mudam a saída. Trate como um rascunho de um estagiário sem licença que nunca viu os seus desenhos.

Revisão humana. Uma pessoa com a competência e a autoridade para a decisão lê a sugestão, edita, rejeita ou aceita num processo conferido. Revisar não é «o modelo soou confiante». É um indivíduo nomeado aplicando juízo a um escopo concreto.

Evidência de validação. Comparação independente contra algo que não compartilha o mesmo modo de falha: um cálculo à mão de um caso reduzido, uma solução conhecida de um livro, um segundo motor de análise, um resultado de laboratório ou uma suíte de regressão em que você já confia. Uma captura de um chat não é evidência.

Se um entregável não consegue dizer qual papel está desempenhando, assuma que é uma sugestão.

O que um solver realmente faz

Um solver estrutural (OpenSees, um programa comercial de elementos finitos, mesmo um script curto que implementa T = 2π√(m/k) para um oscilador SDOF declarado) opera sobre um modelo que você definiu. Aplica um método numérico a esse modelo. Equilíbrio, compatibilidade e hipóteses constitutivas vivem no modelo e no método, não na prosa em português ou inglês.

Isso não torna o solver «verdadeiro». Torna o cálculo reproduzível. Você pode mudar a rigidez de uma mola, rodar de novo e ver o período se mover. Pode imprimir a tangente, os residuais, o autovalor. Pode arquivar o baralho de entrada.

A reproduzibilidade é o piso. A correção ainda exige que o modelo coincida com a mecânica pretendida, que as unidades sejam consistentes e que alguém compare o resultado com uma conferência independente.

O que um modelo de linguagem realmente faz

Um modelo de linguagem prevê continuações prováveis de texto. Não conhece as suas seções a menos que você as tenha colado. Não impõe equilíbrio. Não abre ASCE 7, Eurocódigo 8 ou NSR-10 como uma base controlada a menos que você tenha construído essa camada de recuperação — e mesmo então a frase gerada não é o texto legal.

Pode emitir um trecho plausível de OpenSees com a transformação geométrica errada. Pode citar uma cláusula que não existe. Pode misturar edições. Essas falhas são normais para a tecnologia. São inaceitáveis como base de projeto sem revisão.

Uma distinção trabalhada, não um projeto

Suponha que a pergunta de engenharia seja o período não amortecido de um oscilador de um grau de liberdade com massa m e rigidez k declaradas.

• Cálculo determinístico: compute T = 2π√(m/k) num ambiente conferido, com as unidades escritas. Arquive m, k e T.
• Sugestão de IA: um chat responde «uns 0.4 segundos». Esse número não tem pé até o cálculo acima existir.
• Revisão humana: um engenheiro confirma que a idealização SDOF é sequer a pergunta certa (muitas vezes não é, para um edifício).
• Evidência de validação: para este caso de brinquedo, a expressão em forma fechada é a referência. Para um modelo elástico de vários andares, a evidência parece comparação com um segundo modelo, um exemplo de livro com frequências publicadas ou uma regressão de solver — não o acordo com um chatbot.

Este exemplo é pedagógico. Não é o período de um edifício, um período aproximado de norma nem um substituto da análise modal de um sistema real.

Um fluxo que mantém os papéis honestos

1. Declare a pergunta de engenharia e a conferência de aceitação antes de qualquer prompt (o que faria você desconfiar da resposta?).
2. Use um modelo, se for o caso, para redigir entrada, comentários ou uma lista de controle.
3. Um humano edita geometria, restrições, materiais e opções de análise até ser dono do modelo.
4. Um solver roda. Avisos, não convergência e mecanismos inesperados são resultados de primeira ordem.
5. Uma conferência independente é registrada. Se você não consegue nomeá-la, não tem evidência de validação.
6. Só então um engenheiro responsável aceita o resultado num entregável.

Pule um passo e você volta à sugestão.

Erros comuns

• Pedir a um chat «a armadura requerida» ou «o cisalhamento de pavimento» e colar a frase num relatório.
• Tratar citações geradas de normas de projeto como a norma.
• Confiar num arquivo OpenSees ou Python gerado porque roda. Executar não é verificar.
• Usar o mesmo modelo tanto para produzir o número quanto para «confirmá-lo».
• Chamar de «validação» uma pontuação de confiança, uma resposta mais longa ou um rastro de chain-of-thought.

Limitações

Este artigo não classifica assistentes comerciais, não especifica uma jurisdição e não define o procedimento de QA de um escritório. Observações de SDOF em forma fechada não são análise modal de edifícios. As referências a solvers nomeiam uma classe de ferramentas; não endossam uma versão concreta nem um arquivo de entrada.

Sistemas de IA mudam. Um fluxo que era inseguro no ano passado não se torna automaticamente seguro porque um fornecedor acrescentou «citações». Citações ainda precisam ser abertas, conferidas de edição e aplicadas por uma pessoa autorizada a aplicá-las.

Contexto profissional

A prática licenciada, a responsabilidade profissional e os cálculos carimbados são constructos legais e profissionais. Não se transferem a um provedor de modelo. Se a sua jurisdição exige conferências documentadas, uma transcrição de LLM não atinge esse patamar. Se você é estudante, a mesma disciplina vale: o ponto do exercício é que você consiga defender o número.

Material relacionado neste site pode percorrer um primeiro modelo elástico de OpenSees ou teoria de dinâmica. Essas entradas ainda não substituem a análise específica de um projeto. Use-as para praticar os quatro papéis, não para pulá-los.

Referências

• Documentação do OpenSees — opensees.github.io/OpenSeesDocumentation. Documentação oficial do solver, não uma autoridade de IA.
• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0) — nist.gov/itl/ai-risk-management-framework. Útil para falar de medição e risco residual; não é uma norma de projeto estrutural.
• Chopra, A. K. Dynamics of Structures. Use uma edição impressa ou licenciada para a teoria. Este artigo não a reproduz.

Avaliação e limitações

Trate as notas abaixo como contexto de avaliação, não como um cálculo ou uma verificação comprovados.

Avalie qualquer fluxo assistido por IA nomeando qual dos quatro papéis cada artefato ocupa. Se você não consegue apontar um cálculo determinístico, um revisor nomeado e evidência de validação registrada, a saída ainda é uma sugestão. Este artigo não valida uma ferramenta de fornecedor, um prompt nem uma versão de modelo.