Reduzindo o fpk na Alvenaria Estrutural: Ponderadores de Carga e Redução de Sobrecarga no TQS

Ao dimensionar um edifício em alvenaria estrutural, o fpk (resistência característica à compressão do prisma) é o parâmetro que define diretamente o custo do bloco. Um fpk menor significa blocos mais baratos, logística mais simples e, em muitos casos, a viabilidade do próprio empreendimento.

Neste artigo, mostramos como dois ajustes normativos — correção dos coeficientes de ponderação Psi e redução de cargas variáveis da NBR 6120:2019 — impactam o dimensionamento real de um edifício de 17 pavimentos processado no TQS Alvest.


O projeto de estudo

  • 17 pisos (Tipo 1 ao 3, Tipo 4 ao 7, Tipo 8 ao 10, Tipo 11 ao 13, Tipo 14, Rooftop e Reservatórios)
  • Alvenaria estrutural com blocos vazados de concreto, espessura 14 cm
  • 40 subestruturas por pavimento
  • Altura total de 49,70 m
  • Vento: V0 = 33 m/s, Categoria IV, Classe B

Modelos analisados

ModeloDescrição
OriginalCritérios default do TQS
PsisCoeficientes Psi corrigidos conforme NBR 8681
RedSobrecPsis corrigidos + Redução de sobrecarga conforme NBR 6120:2019

Ajuste 1: Coeficientes de ponderação Psi

O que são os coeficientes Psi

Os coeficientes Psi (Ψ₀, Ψ₁ e Ψ₂) definem como as ações variáveis participam das combinações de carregamento:

  • Ψ₀ — Fator de combinação (ELU)
  • Ψ₁ — Fator frequente (ELS-Fr)
  • Ψ₂ — Fator quase-permanente (ELS-QP)

O problema: valores default do TQS

CoeficienteDefault TQSNorma (NBR 8681)
Ψ₀ (ELU)0,80,5
Ψ₁ (ELS-Fr)0,70,4
Ψ₂ (ELS-QP)0,60,3
  • Critérios default do TQS
  • Critérios corrigidos Psi

Impacto no dimensionamento

A correção dos Psi não altera as cargas verticais nem a tensão de compressão pura (falv,c). O que muda é a participação da carga acidental nas combinações com vento, alterando o equilíbrio entre compressão e flexão — e consequentemente o fpk necessário.


Ajuste 2: Redução de cargas variáveis (NBR 6120:2019, item 6.12)

Fundamentação normativa

A NBR 6120:2019 permite reduzir as cargas variáveis quando há pisos adjacentes com mesmo tipo de uso. O princípio é estatístico: a probabilidade de todos os pavimentos estarem simultaneamente carregados diminui conforme o número de pisos aumenta.

Aplicação no TQS

PisosRedutorPavimento
120,00Tipo 11 ao 13
110,20Tipo 11 ao 13
100,40Tipo 8 ao 10
090,60Tipo 8 ao 10
01–080,60Tipo 1 ao 10
  • Tabela redutores TQS

Impacto no dimensionamento

A redução de sobrecarga diminui diretamente a carga vertical acumulada, reduzindo tanto a tensão de compressão (falv,c) quanto o fpk necessário.


Resultados comparativos

  • Comparação modelos TQS

Resumo geral

Modelofalv,c médiofalv,c máxfpk médiofpk máxΔ falv,cΔ fpk
Original219,0299,81151,91489,0
Psis219,0299,81122,21416,90,0%-2,6%
Psis + RedSobrec205,8269,51074,91367,7-6,0%-6,7%

Conclusão

A simples conferência de dois parâmetros de carregamento — coeficientes Psi e redução de sobrecarga — pode gerar uma economia de quase 7% no fpk de dimensionamento sem qualquer alteração na geometria ou detalhamento do projeto.

Para edifícios altos em alvenaria estrutural, onde o fpk dos pisos inferiores governa a especificação dos blocos, essa diferença é significativa.


Estudo realizado pela equipe BRGT Estruturas utilizando o TQS Alvest V25 e ferramentas internas desenvolvidas em Python.


Gostou do conteúdo? Nos siga nas redes sociais e não perca nenhuma novidade!!

Testei 6 combinações de LLMs para um bot corporativo de busca. O resultado me surpreendeu.


O problema

Aqui na BRGT Engenharia lidamos todos os dias com uma grande quantidade de arquivos: propostas comerciais, projetos estruturais, planilhas de orçamento, plantas DWG, relatórios de sondagem, contratos e até scripts de automação.

O problema era simples (e comum em qualquer empresa):
a informação existia, mas encontrar rápido era difícil.

A solução que criamos foi um bot no Telegram com inteligência artificial que indexa os arquivos do servidor e responde perguntas em linguagem natural.

Exemplo real:

“Qual foi o valor do orçamento da última proposta?”

O bot busca nos arquivos, interpreta e responde.


Como o sistema funciona (arquitetura RAG)

O sistema usa uma arquitetura RAG (Retrieval-Augmented Generation) com duas etapas de LLM:

1. Extração de termos
O modelo converte a pergunta do usuário em palavras-chave otimizadas para busca.

2. Geração de resposta
Outro modelo recebe os arquivos encontrados como contexto e gera a resposta final.

A grande dúvida era:

  • Qual combinação de modelos usar?
  • Um modelo caro?
  • Um modelo local gratuito?
  • Um modelo barato na nuvem?

Para evitar achismo, rodamos 6 benchmarks sistemáticos.


Metodologia

Avaliação automatizada

Todos os testes seguiram o mesmo processo:

  • 10 consultas reais simulando o uso diário
  • Avaliação automática em 5 critérios:
    • Precisão
    • Completude
    • Relevância
    • Clareza
    • Utilidade
  • Uma resposta de referência considerada nota 10

Tudo comparado de forma objetiva.

Nota metodológica importante

Todas as notas apresentadas são relativas a uma resposta de referência avaliada automaticamente pelo modelo mais avançado disponível no dia do teste: OpenAI GPT-5.2.
Isso garante padronização, consistência e comparação objetiva entre os benchmarks.


Modelos testados

ModeloTipoCusto input (1M tokens)Custo output (1M tokens)
GPT-5.2API$1,25$10,00
GPT-5-miniAPI$0,25$2,00
GPT-5-nanoAPI$0,05$0,40
GPT-4o-miniAPI$0,15$0,60
Ollama qwen2.5:7bLocalGrátisGrátis

O índice continha cerca de 1.100 arquivos com busca full-text.


Benchmark 1 — Local vs Nuvem

Pergunta: modelo local compete com API?

ModeloNotaTempo médio
GPT-4o-mini5,42,0 s
Ollama qwen2.5:7b4,46,1 s

Insight importante:

O problema não era só o modelo — era usar o mesmo modelo fraco para extrair termos e responder.


Benchmark 2 — Usando modelos diferentes para cada etapa

Combinação (extração + resposta)NotaTempo
4o-mini + 5.27,37,2 s
Ollama + 5.26,58,0 s
5.2 + 4o-mini6,12,4 s
5.2 + Ollama5,97,1 s
4o-mini + 4o-mini5,22,5 s
4o-mini + Ollama4,67,0 s
Ollama + 4o-mini4,34,1 s
Ollama + Ollama3,98,1 s

Insight:

O modelo de resposta impacta muito mais na qualidade final do que o de extração.


Benchmark 3 — Família GPT-5

CombinaçãoNotaCusto (10 consultas)
5.2 + 5-nano8,0$0,03
5.2 + 5-mini7,5$0,08
5-nano + 5.26,6$0,48
5-mini + 5.26,3$0,48
5-nano + 5-mini6,2$0,01
5-mini + 5-nano6,2$0,01
5-mini + 5-mini6,1$0,08
5-nano + 5-nano5,9$0,01

Conclusão:

Modelo forte para extrair + modelo barato para responder manteve alta qualidade com custo baixíssimo.

⚠️ Descoberta Crítica:

Modelos menores e mais baratos retornaram string vazia na etapa de extração de termos em múltiplos testes.
A tarefa parece simples, mas exige capacidade de raciocínio que modelos compactos ainda não entregam com confiabilidade.


Benchmark 4 — Variação do prompt do sistema

PromptNotaDescrição
Especialista técnico7,9Persona de engenheiro civil sênior
Original7,3Genérico
Detalhado7,2Contexto da empresa
Passo-a-passo7,1Raciocínio guiado
Anti-alucinação6,0Regras rígidas

Prompts muito restritivos pioraram o resultado.


Benchmark 5 — Prompt de extração

TipoNotaObservação
Categorizado7,6Separação por tipo
Original7,5Simples
Expansão semântica6,7Sinônimos técnicos
Contextualizado6,4Regras anti-genérico
Few-shot6,4Exemplos

Conclusão:

Prompt simples funciona.

⚠️ Descoberta Crítica:

Prompts excessivamente restritivos (anti-alucinação) reduziram a utilidade das respostas.
Ao tentar impedir qualquer risco de erro, o modelo passou a responder de forma curta, vaga e pouco prática.


Benchmark 6 — Comparação final de modelos de resposta

ModeloNotaCusto (10 consultas)Tempo
GPT-5.28,6$0,3185,7 s
GPT-5-nano7,7$0,010817,2 s
GPT-4o-mini6,6$0,00791,6 s
Ollama5,9Grátis10 s

O modelo econômico entregou cerca de 90% da qualidade por 3% do custo.


Configuração final (produção)

EtapaEscolha
ExtraçãoModelo robusto (5.2)
RespostaModelo econômico (5.2 nano)
PromptPersona técnica
ExtraçãoSimples e direto

Projeção de custos

UsoConsultas/diaCusto mensal
Leve5~R$ 0,70
Moderado10~R$ 1,40
Intenso50~R$ 6,90
Pesado100~R$ 13,80

O que aprendemos

  1. Separe extração e resposta
  2. O modelo de resposta pesa mais
  3. Modelos baratos não extraem bem termos
  4. Persona técnica melhora respostas
  5. Anti-alucinação excessiva piora
  6. Prompt complexo atrapalha
  7. Local nem sempre compensa

Arquitetura final (resumo simples)

Usuário pergunta no Telegram →
Modelo extrai palavras-chave →
Busca nos arquivos →
Modelo gera resposta →
Resposta enviada.

Simples, rápido e barato.


Código aberto?

O sistema está em produção na BRGT Engenharia.

Os scripts de benchmark podem ser compartilhados para quem quiser implementar.

Stack:

  • Python
  • Telegram Bot
  • OpenAI API
  • SQLite
  • Leitura de PDF, DWG e planilhas

Versão técnica completa

A versão completa do benchmark, com todos os dados, tabelas detalhadas e análises técnicas aprofundadas, está disponível aqui:

👉 Acessar versão técnica completa do benchmark


Gostou do conteúdo? Nos siga nas redes sociais e acompanhe nossos próximos posts.