Uma das coisas que mais adoro na execução de modelos nativos de IA é o senso de propriedade que os acompanha. Eles são privados, eficientes e cada vez mais capazes de iteração após iteração, enquanto os requisitos de hardware continuam a se tornar mais modestos com o tempo. Mas depois de passar alguns meses com o Gemma 4, me deparei com um problema que precisava ser resolvido se eu quisesse confiar nele. Percebi isso pela primeira vez há cerca de uma semana, quando solicitei um resumo de alguns anúncios da Computex 2026, e a resposta, embora convincente, foi completamente alucinatória. a maioria tão detalhado que alguns dos produtos nele descritos simplesmente não existiam.
Agora, francamente, é responsabilidade do usuário compreender as limitações do modelo. Como os modelos locais nem sempre têm informações em primeira mão e, portanto, não têm uma maneira confiável de admitir que não sabem alguma coisa, eles tendem a obter a resposta errada, mas tanto faz. Este é um problema perigoso e decidi corrigi-lo.
Por que Gemma 4 causa alucinações?
A maioria dos modelos domésticos tem esse problema
O resumo da Computex não foi único. Quando percebi que Gemma havia inventado detalhes e anúncios de produtos sobre o evento de maneira convincente, decidi fazer mais experiências para ver até onde iam as “alucinações”. Para minha surpresa (e um tanto horror), descobri que ele pode produzir versões de drivers, especificações de produtos, tendências de preços e tudo mais com base em um conjunto atualizado de informações. As respostas foram autoritárias, fluidas e completamente desligadas da realidade, como seria de esperar. Ficou claro que sempre que o modelo atingisse o limite da sua compreensão, ele simplesmente continuaria a conversa em vez de admitir que não sabia de alguma coisa.
Ao se aprofundar nisso, você entenderá por que isso acontece. Como o modelo foi executado localmente usando Ollama, Gemma não tinha camada de recuperação e, portanto, não tinha acesso às informações atuais. Afinal de contas, não se pode esperar que um modelo compacto de 4,5 mil milhões de parâmetros tenha um mecanismo fiável para reconhecer quando uma questão está para além dos seus limites de conhecimento. Embora eu esteja atento para não encorajar um modelo local, como um serviço LLM baseado em nuvem, o motivo pelo qual isso se torna um risco é que, em um fluxo de trabalho movimentado, muitas vezes é fácil esquecer as limitações do modelo que você está solicitando ou solicitando informações, e se torna um problema difícil se esse modelo não parar para pensar se ele tem acesso a informações válidas e ainda permanece o mesmo que um especialista.
A necessidade de desenvolver uma solução
Reverter esta tendência não foi fácil
O aspecto da verificação de factos na geração de cada relatório de resposta é uma tarefa tediosa, e qualquer pessoa que dependa de uma grande quantidade de investigação realizada utilizando modelos conduzidos localmente não poderá ser incomodada. Então, naturalmente, tive que pensar em outra coisa.
A “solução” óbvia para esse problema que imediatamente me veio à mente foi identificar quando Gemma estava passando por dificuldades e escalar a partir daí. Se Gemma expressasse incerteza, seria possível interceptar essa resposta e encaminhar a consulta para um modelo de nuvem como Claude. A primeira implementação desta solução verificou cada resposta em busca de linguagem de cobertura, como frases como “não tenho certeza”, “meu conhecimento é limitado” ou “não posso confirmar”, antes de passar a consulta e o contexto para Claude. Foi um ponto de partida razoável e uma tentativa bastante promissora de solução. Analisei três aspectos principais da recusa, incluindo uma clara falta de conhecimento, limitações de tempo e a incapacidade de verificar informações de forma independente.
UNCERTAINTY_PATTERNS = (
r"i('m| am) not sure",
r"i don't (know|have enough)",
r"i cannot (answer|help|provide|assist)",
r"i('m| am) unable to",
r"i lack (the )?(knowledge|information|context)",
r"beyond my (knowledge|training|capabilities)",
r"i (don't|do not) have access",
r"my (knowledge|training) (cutoff|only goes)",
r"i('m| am) (not|unsure) (certain|confident)",
r"i (cannot|can't) (confirm|verify|guarantee)",
r"i (would|may) be (wrong|incorrect|mistaken)",
r"knowledge cutoff",
r"training cutoff",
r"cutoff is",
r"still in the future",
r"has not (happened|occurred|taken place) yet",
r"i do not have (information|data|details)",
r"no (information|data|announcements).{0,30}(available|yet|made)",
)
O problema com esta abordagem foi o fato de que Gemma não é fácil de sustentar. Ele preenche os prompts e os preenche de forma convincente, independentemente de a informação subjacente… ser verdadeira. Então falhou imediatamente. A próxima solução viável que pensei sobre onde existia o sinal foi entrada e a natureza da consulta antes que qualquer modelo o toque. Como o roteamento tinha que acontecer no upstream, isso significava classificar a natureza de cada pergunta em vez de verificar cada resposta ex post facto.
Como um script Python resolveu o problema
Uma solução aparentemente simples para um problema complexo
Quando percebi que o roteamento deveria acontecer antes que Gemma visse o prompt, já havia resolvido metade do problema. A solução foi um único script Python executando um backend Flask com uma interface de navegador que abre em qualquer navegador da web. Gemma 4 é executado localmente via Ollama, enquanto Claude pode ser acessado através da API Anthropic usando uma variável de ambiente para autenticação. Curiosamente, nenhum dos modelos está ciente de que o outro existe no ambiente. A tomada de decisão ocorre inteiramente entre camadas.
O roteamento segue regras muito simples. As perguntas classificadas como “sólidas” incluem explicações, brainstorming e tarefas de redação, todas elas deixadas com Gemma. Solicitações de codificação, comparações de produtos e outras consultas factuais são automaticamente direcionadas a Claude. Isto inclui qualquer coisa recente, como preços atuais, anúncios mais recentes ou notícias. Para tornar o processo transparente, a GUI mostra qual modelo realizará a consulta antes de enviar o prompt.
Finalmente encontrei um LLM nativo de código aberto que realmente compete com a IA da nuvem
O código aberto está chegando
Gemma só precisava de um colaborador, não de um substituto
Depois de um curto período de tempo com essa configuração, percebi o melhor dos LLMs locais e baseados na nuvem, e ela também tem uma proposta de valor econômico. A maioria das minhas consultas diárias são feitas localmente, por isso a experiência é privada, rápida e gratuita. Claude só se envolve quando a precisão dos fatos está em jogo. Isso também significa que a sobrecarga da API Anthropic permanece baixa porque o Gemma lida com a interface primária e nenhum modelo precisa executar uma tarefa para a qual não foi projetado. Embora essa possa não ser a solução mais elegante, ela resolve o problema que tive em meu fluxo de trabalho e aposto que essa abordagem, se ajustada para outros fluxos de trabalho, pode fornecer um valor melhor.
