Limitações dos LLMs: alucinação, viés, custo e latência

Antes de comprar IA generativa, é preciso saber o que ela não faz. Cinco limitações reais — alucinação, viés, custo, latência e janela de contexto — determinam quase 100% dos projetos que dão errado em 2026. Este artigo é a contraparte honesta do hype: o que esperar, o que não esperar, e como projetar em torno dessas restrições para evitar prejuízo e frustração.

Por que falar de limitações primeiro

A maior parte do conteúdo sobre IA generativa fala do que ela pode fazer. Útil para inspiração, péssimo para tomada de decisão. Comprar tecnologia pelos pontos fortes sem mapear pontos fracos é o caminho mais curto para o "POC que vira pesadelo em produção".

As cinco limitações deste artigo aparecem em todos os projetos reais — não só nos malfeitos. Reconhecê-las cedo permite escolher arquitetura certa (LLM puro? RAG? Tool calling? Fine-tuning? Humano no loop?) e definir critérios de aceite que não vão ser ressuscitados em pânico no penúltimo dia do prazo.

1. Alucinação

LLM não recupera fatos — gera texto provável. Se a probabilidade puxa para uma formulação plausível mas errada, o modelo afirma com a mesma confiança que afirmaria algo correto. Isso é alucinação.

Onde mais ataca:

Mitigação prática:

  1. RAG ancorado em base curada — força o LLM a responder com base em documentos reais.
  2. Pedir citação verificável em todo prompt fact-heavy.
  3. Critic loop: usar um segundo LLM para revisar a saída do primeiro contra as fontes.
  4. Em domínios críticos (jurídico, médico): revisão humana obrigatória.

Verdade desconfortável: nenhuma das mitigações elimina alucinação. Reduz drasticamente, sim. Zera, não. O design do produto precisa assumir isso e ter fallback quando o usuário pegar um caso errado.

2. Viés

Modelos aprendem dos dados de treino. Se o corpus carrega viés (e carrega), o modelo carrega. Em 2026 os principais labs declaram esforço de mitigação, mas vieses sutis sobreviveram — em tom, em preferências por autoridade, em escolha de exemplos.

Onde mais ataca:

Mitigação:

  1. Não usar LLM para decidir em contextos regulados — LGPD art. 20 dá ao titular o direito de revisão por humano.
  2. Definir conjuntos de teste com casos representativos de minorias e medir se a saída diverge.
  3. Logar input/output e revisar amostragem mensalmente.
  4. Documentar viés conhecido na política interna de uso.

3. Custo

LLM custa por token. Token é mais ou menos uma sílaba longa. Em prosa em português, 1 página A4 ≈ 800 tokens. Uma resposta com contexto RAG injetado pode chegar a 8 mil tokens (entrada) + 2 mil tokens (saída) por turno.

Faixas reais em 2026 (preços orientativos, conferir provedor):

CenárioTokens/mêsCusto estimado/mês
Chatbot interno (50 usuários, 20 turns/dia)~30MR$ 1.200 – R$ 4.500
Atendimento WhatsApp (3.000 conversas/mês)~75MR$ 3.000 – R$ 11.000
Geração de documentos (200 docs longos/mês)~40MR$ 1.600 – R$ 6.000
RAG sobre base com queries pesadas (10k/mês)~80MR$ 3.200 – R$ 12.000

Otimizações que aprendi do jeito difícil:

  1. Cache — perguntas iguais retornam resposta igual. Reduz 30-50% em FAQ-style.
  2. Tier de modelo — Haiku/Sonnet 4.6 para 80% das tarefas rotineiras, Opus só para análise complexa.
  3. RAG com top-k controlado — recuperar 3 chunks em vez de 8 já mantém qualidade na maioria dos casos e corta entrada pela metade.
  4. Sumarização hierárquica — em conversas longas, comprimir turnos antigos antes de reenviar.

4. Latência

LLM é stream — gera token a token. Para responder uma frase de 200 tokens, modelos comerciais levam tipicamente 2-5 segundos para começar a streamar e mais alguns segundos para terminar.

Onde isso é problema:

Mitigação:

  1. Usar streaming sempre que possível — primeira impressão é de velocidade quando os primeiros tokens chegam logo.
  2. Modelos pequenos (Haiku, Llama 3 8B) para tarefas onde latência > precisão.
  3. Pré-computação — para N saídas previsíveis, gerar antes em batch e servir do cache.
  4. Paralelizar passos independentes do workflow.

5. Janela de contexto

Modelos têm uma "memória curta" — quanto cabe no prompt antes de cortar. Em 2026, modelos top-tier oferecem janelas de 200k-1M tokens. Sembra ilimitado, mas dois problemas reais persistem:

Mitigação:

  1. Não despejar tudo no prompt. Recuperar via RAG só o que é relevante para a pergunta atual.
  2. Posicionar o crítico — instruções importantes no início, contexto recuperado no meio, pergunta no final.
  3. Validar com testes do tipo "needle in haystack" para cada modelo escolhido.

Matriz de risco e mitigação

LimitaçãoQuando dói maisMitigação primáriaCusto da mitigação
AlucinaçãoDomínios fact-heavy (jurídico, médico, financeiro)RAG com citação verificável + revisão humanaMédio (engenharia + curadoria)
ViésDecisões sobre pessoas (RH, crédito, saúde)Não delegar decisão final ao LLM; testes de equidadeMédio (compliance)
CustoVolume alto, prompts gigantes, modelo top-tierCache, tier de modelo, RAG enxutoBaixo (mais design que infra)
LatênciaVoz, autocomplete, workflows em cadeiaStreaming, modelos pequenos, pré-computaçãoBaixo
ContextoBases muito grandes, "documento gigante" no promptRAG bem chunkado; posicionamento estratégicoMédio (engenharia de retrieval)

Checklist antes de aprovar projeto LLM em produção

Erros comuns que vejo no mercado

  1. "Vamos fine-tunar para reduzir alucinação." Quase nunca é a resposta. RAG resolve antes, mais barato. (Ver artigo sobre RAG.)
  2. "Modelo X é top no benchmark, vamos usar." Benchmark público não diz nada sobre seu domínio. Faça avaliação interna com perguntas reais.
  3. "Janela de 1M token, podemos jogar tudo lá." Pode, mas vai pagar caro e ainda perder informação no meio.
  4. "Vamos confiar no LLM para tomar a decisão final." Em contextos regulados, decisão automatizada de impacto exige opt-out humano por LGPD.
  5. "Latência não é problema, ninguém reclamou." Ainda. Voice e produtos de massa fazem reclamar — meça antes de escalar.

Conclusão

LLMs em 2026 são ferramentas excelentes — para os problemas certos. As cinco limitações deste artigo não são defeitos a serem "corrigidos" pela próxima versão; são propriedades intrínsecas do paradigma probabilístico que sustenta a tecnologia. Boa engenharia de IA aceita isso e desenha em volta.

Quem entra em projeto de IA achando que vai virar "humano substituído" descobre tarde demais o custo dessa fantasia. Quem entra pensando "ferramenta com restrições conhecidas" entrega valor — e dorme bem.

Quer mapear quais dessas 5 limitações afetam mais o seu caso de uso e desenhar arquitetura em volta? Diagnóstico inicial é gratuito — 45 minutos para entender o problema e dar visão honesta.