IA em português: como avaliar modelos e testar com Ollama

Uma inteligência artificial que “fale português” não se constrói apenas traduzindo a interface de um chatbot. O desafio real é criar sistemas que entendam as variedades do idioma, respondam com precisão sobre assuntos brasileiros e possam ser operados com custos, dados e infraestrutura sob controle local. Segundo o InfoMoney, Lula defendeu a criação de uma IA em português e disse ter desafiado o Conselho Nacional de Ciência e Tecnologia a discutir essa possibilidade. A entrevista não detalha arquitetura, orçamento ou cronograma — e essa diferença entre defender uma ideia e especificar um projeto importa.

Como desenvolvedor, eu separo a discussão em duas perguntas: precisamos treinar um modelo fundacional do zero ou precisamos de serviços de IA que funcionem melhor para quem fala português? A primeira opção exige capital, dados e capacidade computacional em escala. A segunda pode gerar resultados concretos mais cedo, usando modelos existentes, dados brasileiros bem tratados e avaliações rigorosas.

O que significa criar uma inteligência artificial que fale português

Um modelo “falar português” pode significar coisas bem diferentes. Pode ser uma interface traduzida, um modelo treinado para gerar texto em português, um sistema com bom desempenho em tarefas locais ou uma infraestrutura nacional capaz de hospedar e controlar modelos. Essas metas não são equivalentes.

Um chatbot pode produzir frases fluentes e ainda errar uma regra tributária brasileira, confundir órgãos públicos ou tratar uma expressão regional como se fosse um erro. Fluência é uma característica visível; confiabilidade depende de dados, avaliação e desenho do sistema.

Também não existe um único português. Há variação regional, diferenças entre registros formais e informais, vocabulário técnico, gírias e usos próprios de áreas como direito, saúde e administração pública. Um produto que funciona para redigir e-mails pode não servir para analisar documentos jurídicos ou atender cidadãos.

Modelo, dados e infraestrutura são problemas distintos

Quando falo em IA, muita gente pensa apenas no modelo de linguagem. Em produção, eu trato o modelo como uma parte de um sistema maior: entram dados, políticas de acesso, mecanismos de busca, avaliação, observabilidade, segurança e experiência de uso.

Modelo: prevê e gera texto; pode ser aberto, comercial ou treinado especificamente para uma tarefa.
Dados: determinam boa parte do conhecimento disponível e dos vieses do sistema. Licença, qualidade e representatividade importam.
RAG: recupera documentos relevantes no momento da consulta e os fornece ao modelo como contexto.
Infraestrutura: inclui GPUs, armazenamento, redes, operação, controle de acesso e monitoramento de custos.
Avaliação: verifica se o sistema responde corretamente, respeita limites e continua funcionando após mudanças.

Treinar do zero não resolve automaticamente a falta de conteúdo brasileiro. Um modelo pode custar muito para desenvolver e ainda reproduzir erros ou responder mal a perguntas específicas. Para muitos produtos, combinar um modelo existente com busca em fontes confiáveis é uma decisão mais pragmática.

Treinar do zero, ajustar um modelo ou usar RAG?

Na prática, há três caminhos frequentes. Treinar um modelo fundacional do zero dá mais controle sobre a construção, mas exige um volume enorme de dados, computação, pessoas especializadas e manutenção contínua. Não é a primeira escolha para a maioria das empresas ou equipes de produto.

O ajuste fino adapta um modelo pré-treinado a um comportamento ou domínio. Pode ajudar com formato de resposta, classificação ou vocabulário especializado. Mas não é uma forma confiável de “instalar” fatos atualizados na memória do modelo: conhecimento factual pode ficar incompleto, desatualizado ou difícil de corrigir.

Com RAG, o sistema pesquisa uma base de documentos no momento da pergunta e entrega trechos relevantes ao modelo. Isso facilita atualizar conteúdo sem retreinar, citar fontes internas e restringir respostas ao material disponível. A qualidade, porém, depende da busca: documentos mal segmentados ou uma recuperação ruim produzem respostas ruins, mesmo com um modelo potente.

Eu começaria por um modelo multilíngue já disponível e mediria seu desempenho em português brasileiro. Depois, adicionaria RAG se o caso depender de documentos próprios ou atualizados. Só consideraria ajuste fino após identificar uma falha recorrente que prompt e recuperação não resolvem. Treinar do zero fica para situações em que controle, escala e justificativa econômica realmente sustentem a decisão.

Soberania de IA não é só ter um modelo nacional

Se a preocupação é depender menos de fornecedores estrangeiros, olhar apenas para o idioma é insuficiente. Um sistema pode responder em português e ainda depender de APIs externas, GPUs importadas, serviços de nuvem de terceiros ou licenças que limitam o uso.

Eu avaliaria soberania como um conjunto de capacidades: governar os dados, escolher onde executar inferência, auditar componentes, negociar custos e manter uma alternativa operacional caso um fornecedor mude preços ou condições. Isso não exige que toda equipe construa seu próprio modelo. Exige entender as dependências e ter opções reais.

Também é importante não confundir código aberto com ausência de restrições. Pesquise a licença do modelo, os limites comerciais e as condições de redistribuição. Verifique ainda se o provedor registra prompts ou utiliza dados enviados para treinamento. Em aplicações com informação sensível, esse ponto deve entrar na análise antes da integração.

Como comparar alternativas de verdade

Eu não escolheria um modelo apenas por uma demonstração impressionante ou por uma tabela genérica de benchmarks. Montaria um conjunto de testes ligado ao produto. Para um assistente de suporte, por exemplo, incluiria perguntas frequentes, solicitações ambíguas, erros comuns de digitação e casos em que a resposta correta é admitir que não sabe.

Além da qualidade, mediria latência, custo por tarefa, taxa de falha e capacidade de operar dentro dos requisitos de privacidade. Um modelo menor executado localmente pode ser suficiente para classificação e extração; um modelo maior pode ficar reservado para perguntas complexas. Essa arquitetura por tarefa costuma ser mais eficiente do que enviar tudo para o modelo mais caro.

Na Prática: testar um modelo local respondendo em português

Para um primeiro experimento, dá para executar um modelo localmente com Ollama e chamar sua API HTTP a partir de Python. Isso não cria um modelo brasileiro nem garante respostas corretas. Serve para testar o fluxo, comparar prompts e avaliar um conjunto de perguntas sem enviar cada consulta a uma API externa.

Instale o Ollama, baixe um modelo compatível com sua máquina e inicie o serviço. O exemplo abaixo usa o identificador qwen2.5:3b; a disponibilidade e o desempenho dependem da versão instalada e dos recursos do computador. Em seguida, instale a biblioteca requests.

ollama pull qwen2.5:3b
python -m pip install requests

Este script envia uma pergunta e imprime a resposta. Defini explicitamente o idioma e pedi que o modelo sinalize incerteza. Esse tipo de instrução ajuda a orientar o comportamento, mas não substitui validação nem garante que o modelo sempre obedecerá.

import requests

URL = "http://localhost:11434/api/chat"
MODEL = "qwen2.5:3b"

payload = {
    "model": MODEL,
    "stream": False,
    "messages": [
        {
            "role": "system",
            "content": (
                "Responda em português brasileiro, com clareza e precisão. "
                "Se não tiver informação suficiente, diga o que está faltando. "
                "Não invente fontes, números ou citações."
            ),
        },
        {
            "role": "user",
            "content": "Explique a diferença entre fine-tuning e RAG.",
        },
    ],
}

try:
    response = requests.post(URL, json=payload, timeout=120)
    response.raise_for_status()
    data = response.json()
    print(data["message"]["content"])
except requests.RequestException as exc:
    print(f"Falha ao consultar o modelo local: {exc}")

Por que usar uma instrução de sistema? Ela deixa explícitos idioma, tom e comportamento esperado. Por que usar um timeout? Porque inferência local pode demorar, especialmente em hardware limitado. Por que capturar erros HTTP? Porque o serviço pode não estar ativo, o modelo pode não ter sido baixado ou a máquina pode ficar sem recursos.

Para transformar o teste em uma avaliação minimamente útil, eu guardaria perguntas representativas e respostas esperadas, executaria cada modelo com o mesmo conjunto e compararia resultados. Não avaliaria apenas se a resposta “soa natural”. Verificaria fatos, cobertura, consistência, tempo de resposta e se o sistema reconhece quando não consegue responder.

Erros comuns ao desenvolver aplicações com IA em português

Usar fluência como sinônimo de precisão. Uma resposta convincente pode conter dados inventados. Em contextos críticos, exija fontes verificáveis e valide a saída.
Tratar prompt como solução para tudo. Instruções melhoram o comportamento, mas não atualizam conhecimento nem corrigem uma busca ruim.
Aplicar fine-tuning para dados que mudam todo dia. Para políticas, preços ou documentação atualizada, RAG costuma facilitar manutenção e rastreabilidade.
Ignorar a licença e a privacidade. Antes de enviar dados a um serviço, confira retenção, uso para treinamento, região de processamento e obrigações contratuais.
Testar apenas com perguntas fáceis. Inclua ambiguidades, erros de digitação, perguntas fora do escopo e exemplos de diferentes registros do português.
Confundir modelo aberto com sistema gratuito. Hospedagem, GPUs, armazenamento, operação e segurança também têm custo.
Não monitorar mudanças. Trocar versão de modelo, prompt ou índice de busca pode alterar respostas. Mantenha testes de regressão antes de publicar.

Uma armadilha recorrente é construir um chatbot genérico antes de definir o problema. Eu começaria pelo trabalho que a aplicação deve resolver: reduzir tempo de busca em documentação, classificar chamados, auxiliar na redação ou responder sobre uma base específica. Depois escolheria a arquitetura mínima e mediria o ganho contra uma solução sem IA.

O que essa proposta pode significar para quem programa

Uma iniciativa de IA em português pode ser relevante se resultar em dados de qualidade, pesquisa, infraestrutura compartilhada, padrões de avaliação e produtos úteis. Só anunciar um modelo não basta. É preciso explicar quem pode usá-lo, como será mantido, quais dados entram no treinamento e como erros e vieses serão acompanhados.

Para desenvolvedores, a consequência prática é menos abstrata. Modelos melhores em português podem reduzir trabalho de adaptação, melhorar busca semântica e tornar interfaces mais naturais. Mas ainda caberá a cada equipe cuidar de autenticação, permissões, proteção de dados, testes e limites de uso. O modelo não substitui engenharia de software.

Eu acompanho essa discussão com uma régua técnica: problema definido, dados legítimos, avaliação pública ou reproduzível, custo sustentável e independência operacional mensurável. Sem esses elementos, “IA que fale português” corre o risco de virar apenas uma promessa de marketing; com eles, pode se transformar em infraestrutura útil para equipes e cidadãos.

Perguntas frequentes sobre IA em português

É necessário criar um modelo de linguagem do zero para ter uma IA brasileira?

Não. É possível desenvolver aplicações brasileiras com modelos existentes, dados locais, RAG e avaliação específica. Treinar do zero pode fazer sentido em cenários de grande escala ou controle estratégico, mas é caro e não é requisito para criar um produto útil em português.

RAG faz o modelo aprender português melhor?

Não diretamente. RAG fornece documentos relevantes como contexto para uma resposta. Ele pode melhorar o acesso a informações brasileiras e atualizadas, mas não altera por si só a capacidade linguística do modelo.

Posso usar um modelo local em produção?

Sim, desde que o modelo e sua licença permitam o uso previsto e que a equipe consiga operar hardware, segurança, atualizações e monitoramento. Teste desempenho e qualidade no seu caso real; uma execução local não é automaticamente mais barata ou mais segura.

Como avaliar se um modelo responde bem em português brasileiro?

Monte um conjunto representativo do seu domínio, com respostas de referência e casos em que o sistema deve admitir incerteza. Compare modelos com as mesmas perguntas e avalie precisão, consistência, latência, custo e comportamento diante de informações insuficientes.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.