Houssan Ali Hijazi - Software Developer

Como construí o MitAI: um chatbot que responde preço, cotação e dúvidas sobre lojas sem inventar dados

2026-07-29T11:00:00-03:00

Como construí o MitAI: um chatbot que responde preço, cotação e dúvidas sobre lojas sem inventar dados

Open WebUI + function calling + RAG na frente da API do Lojas Paraguai, pra fechar a porta que mais mata projeto de chatbot em e-commerce: o modelo alucinar preço.

🧢 Por que "MitAI"

O nome é um trocadilho: "mitã'i" (ou mitaí) significa "criança" no guarani paraguaio, forma carinhosa e cotidiana de chamar os pequenos no Paraguai. Aqui vira "mit-AI", a IA do Lojas Paraguai.

🎯 O problema

No Lojas Paraguai o usuário quer três coisas: "quanto custa esse produto?", "a quanto tá o dólar hoje?" e "essa loja é confiável?". Parece trabalho perfeito pra um chatbot. Mas num site de comparação de preços existe uma falha que mata o projeto inteiro: o modelo inventar o preço.

LLM sozinho, sem ferramentas, alucina com confiança. Testei a mesma pergunta, "iphone 17 pro max 256gb", três vezes seguidas, e recebi três preços diferentes. Num site onde preço correto é o produto, isso é inaceitável. O modelo precisa buscar o dado real e atualizado, não recitar de memória.

🛠️ A solução: Open WebUI + tools na própria API

Em vez de deixar o modelo responder de cabeça, ele chama ferramentas que batem no backend do Lojas Paraguai:

dolar: cotação real do dia e gráfico semanal
buscar-produto / detalhe-produto: preço, lojas que vendem e detalhes do produto
lojas: informações das lojas cadastradas

Fluxo é function calling clássico:

Modelo decide qual tool chamar, a partir da pergunta do usuário
Backend executa a chamada na API interna do catálogo
API devolve o resultado
Modelo formata a resposta em linguagem natural, sem alterar o dado

O resultado: aquele mesmo "iphone 17 pro max 256gb" que antes dava três preços diferentes agora retorna sempre o valor do banco, igual em toda tentativa. Preço não vem mais da imaginação do modelo, vem do banco.

🧩 Por que Open WebUI

Open WebUI é uma plataforma open source que roda em Docker e serve como camada de orquestração na frente do modelo. Criei um modelo próprio com base no gpt-4.1-mini da OpenAI, adicionei minha FAQ na base de conhecimento (RAG) e criei as tools de acesso à minha API.

Ele expõe uma API compatível com OpenAI (/api/chat/completions), então o backend do Lojas Paraguai conversa com o Open WebUI exatamente como conversaria direto com a OpenAI, troca de provider é transparente. E já traz pronto: gestão de tools, workspaces, RAG, chaves de API e base de conhecimento. Isso poupou de construir do zero todo o encanamento de function calling e recuperação de contexto.

⚙️ A camada que fecha a porta pra alucinação

Passar o JSON cru da API pro modelo não resolve. Testei assim primeiro, e sem enriquecer a resposta o modelo simplesmente inventa em cima do que falta:

Cotação do dólar sem o cálculo pronto → modelo chuta uma cotação errada pra converter preço
Slug de produto sem URL montada → modelo adivinha um caminho, que dá 404

A correção foi uma camada de enrich() na API, que já entrega o dado mastigado, exatamente o que a tool deveria trazer:

cotação × dólar = valor em BRL já calculado
slug → URL completa e válida do produto

Com isso o modelo não tem mais espaço pra "completar" nada: o dado que falta pra montar a resposta já vem pronto na tool.

Fechei ainda mais a porta com temperature = 0.2. Chatbot não é lugar pra criatividade, quero a resposta mais determinística possível em cima do dado que a tool entregou, não variação estilística. Temperatura baixa reduz a margem do modelo pra "florear" e inventar em cima do fato.

🎓 Principais lições

Dados crus não bastam. Se falta um cálculo ou uma montagem de URL pro modelo terminar a resposta, ele preenche o vazio inventando. Enriquecer na API, não confiar que o modelo "resolve" em cima do JSON cru.
Num domínio específico, LLM é orquestrador, não fonte da verdade. Ele decide o que buscar (qual tool, com quais parâmetros); o dado sempre vem da API.
Alucinação é o comportamento padrão quando a tool falha ou o dado chega incompleto. Não é uma falha rara do modelo, é o que ele faz por padrão quando falta contexto.
Temperatura baixa em chatbot factual não é sobre estilo, é sobre correção. Menos variação = menos chance do modelo se afastar do dado real que a tool trouxe.

🔗 Onde testar

Chat disponível em www.lojasparaguai.com.br/mitai. Além do site, o MitAI também está no app mobile do Lojas Paraguai.

Como reduzir o custo de categorizar milhares de produtos treinando um modelo local

2026-06-29T11:00:00-03:00

Categorização Híbrida de Produtos: Sklearn local + IA como fallback

Como reduzimos o custo de categorizar milhares de produtos treinando um modelo local que resolve parte dos casos a custo zero antes de chamar uma LLM.

O problema

O catálogo do Lojas Paraguai recebe milhares de produtos novos vindos do crawler, e cada um precisa de categoria e marca para aparecer corretamente no site. Categorizar à mão é inviável, e a primeira solução automatizada, enviar todos os produtos para uma LLM, funcionava, mas com dois custos altos:

Tempo: alguns segundos por batch via API (Ollama/Google/OpenAI).
Dinheiro: cada batch de produtos era uma chamada de API paga, mesmo para casos óbvios como "Samsung Galaxy A50" → Smartphones / Samsung.

A maioria dos produtos é trivial de classificar. Pagar uma LLM para resolver o óbvio não fazia sentido.

A solução

Uma estratégia híbrida em duas fases, implementada no comando categorize_products_hybrid:

Fase 1, Sklearn (local, custo zero, mais rápido) Um classificador treinado com os próprios dados do banco prediz categoria e marca a partir do nome do produto. Se a confiança for ≥ ao threshold (padrão 0.75), o resultado é aceito direto.
Fase 2, LLM (fallback, tem custo, mais lento) Só os produtos em que o modelo local ficou inseguro vão para a IA (via LiteLLM, padrão gemini-2.5-flash-lite), que retorna nomes de categoria/marca resolvidos contra o banco por um mapa de aliases. Esse custo de api é cortado com a possibilidade do uso de modelos locais.

A fração que o modelo local resolve sozinho depende do mix de produtos: em itens comuns é alta, na cauda longa (nomes ruins, produtos raros, marcas obscuras) a confiança cai e a LLM assume. Cada produto que o Sklearn resolve é tempo e custo de API economizados.

Comparativo por batch de 50 produtos (mesma carga nas duas colunas):

Métrica	Sklearn (local)	LLM (se tudo fosse IA)
Tempo/batch (50)	<50ms	alguns segundos
Custo API/batch	0	~0.005 USD
Acurácia	cat ~94% · marca ~90%	~95–98% (estimado)

Como resolvemos

1. Treinamos um modelo para rodar localmente

O comando train_category_brand_model treina dois classificadores independentes, um para categoria (~1000 classes) e outro para marca (~200), salvos como pickles separados.

O pipeline é TF-IDF + SGDClassifier, gera os modelos como pickle:

crawler/data/models/categoria_classifier.pkl
crawler/data/models/marca_classifier.pkl

lnp train_category_brand_model

Esse é o ponto-chave: o modelo roda 100% local, sem API, sem rede, sem custo por predição. Carregado uma vez, classifica milhares de produtos por segundo. E como é treinado com os dados do próprio banco, retorna IDs diretos de categoria e marca, sem necessidade de resolução de nomes.

2. Orquestramos as duas fases com threshold de confiança

O processor_hybrid.py decide por produto: aceita a predição do Sklearn se a confiança passa do threshold, senão acumula em lotes para a LLM. O threshold é o botão de ajuste entre custo e qualidade:

Threshold	Efeito
0.50	Aceita mais predições locais → menos IA, mais barato, menor precisão
0.75 (padrão)	Equilíbrio entre custo e qualidade
0.95	Só aceita predições muito confiantes → mais IA, mais caro, maior precisão

Quanto cada threshold resolve localmente depende do mix de produtos do lote, não é um percentual fixo.

Resultados

Saída real de uma execução sobre o backlog de produtos não categorizados:

📊 Resumo Categorização
  Modo               HÍBRIDO
  Total processado   164
  Sklearn            80 (49%)
  IA                 84 (51%)
  Cat adicionada     98
  Marca adicionada   84
  Sem categoria      66
  Cat novas          34
  Erros              1

Medindo 4 execuções seguidas (764 produtos do backlog), o modelo local resolveu ~36% a custo zero e o restante foi para a LLM, uma economia de custo de ~1,5× neste cenário.

⚠️ Importante: esse teste consome o backlog acumulado de casos difíceis (a cauda longa que sobrou sem categoria), o pior cenário para o modelo local. A fração resolvida cai a cada execução (49% → 37% → 27% → 32%) conforme os fáceis são esgotados. Em produção contínua, com produtos comuns chegando do crawler e retreino frequente, a fração local tende a ser maior, mas isso depende do mix real de cada dia.

Lições

Nem todo problema de classificação precisa de LLM. Um TF-IDF + classificador linear treinado nos próprios dados resolve boa parte dos casos em menos de 1ms e a custo zero, quanto mais comum o produto, maior a fatia que ele cobre.
A LLM brilha como fallback, não como primeira linha: ela cuida dos casos ambíguos, genéricos ou novos que o modelo local nunca viu.
Modelo local melhora com o tempo: cada produto categorizado (por IA ou revisão) vira dado de treino para o próximo train_category_brand_model, reduzindo progressivamente a dependência da LLM.

Como agrupar 200k produtos de lojas diferentes com embeddings e consenso multi-LLM

2026-06-15T10:00:00-03:00

Contexto

O lojasparaguai.com.br é um comparador de preços de produtos das lojas do Paraguai, Ciudade del Este em sua maioria. O sistema obtem os dados dos preços dos produtos diariamente e atualiza na base de dados. O grande desafio enfrentado pelo projeto é o agrupamento de produtos, onde o mesmo produto pode ter nomes diferentes na lojas, deixando o agrupamento complexo de ser feito.

🎯 O problema

Várias lojas vendem o mesmo produto, mas cada uma escreve o nome de um jeito:

Loja A: iPhone 17 Pro Max 256gb Titânio - Apple
Loja B: APPLE IPHONE 17 PROMAX 256 GB Cor Titanium
Loja C: iPhone17 Pro Max - 256GB - novo lacrado

Para mostrar a comparação de preços em uma única página do produto, eu preciso saber que os três são o mesmo item. A primeira solução foi criar uma área na painel onde faríamos esse agrupamento manualmente, buscando produto, selecionando os produtos das lojas, subindo a foto e as especificações. Com 200k+ produtos no banco, agrupar manualmente é muito trabalhoso. Foram feitas algumas tentativas de automatizar esse processo. Abaixo mostro como foi o caminho.

🔧 Primeira tentativa: TF(Frequência do Termo)-IDF(Frequência Inversa do Documento)

Comecei pelo básico, TF-IDF + similaridade. Funciona mais ou menos assim: cada nome vira um vetor de palavras com pesos, e eu comparo os vetores.

Problemas encontrados:

TF-IDF é "burro", não entende que Promax e Pro Max são a mesma coisa
Em português, sinônimos e variações de marca quebram tudo (Galaxy S24 vs Samsung S24)
Acessórios acabavam agrupados com o produto principal (capa iPhone 17 virava grupo do iPhone 17)
Produto novo no catálogo? O algoritmo nunca tinha visto e errava feio

Tentei melhorar com regras manuais, listas de sinônimos, regex para normalizar marcas, blacklist de palavras como "case", "capa", "película". Virou um Frankenstein de manutenção infinita.

🧠 Segunda tentativa: embeddings semânticos

Troquei TF-IDF por Sentence-Transformers (BERT pré-treinado para português). Em vez de comparar palavras, compara significado.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')
emb = model.encode([
    'iPhone 17 Pro Max 256gb',
    'APPLE IPHONE 17 PROMAX 256 GB'
])
# similaridade: 0.94 (mesmo item)

Ganho imediato:

Promax ≈ Pro Max (o modelo entende que é uma variação da mesma palavra)
Galaxy ≈ Samsung Galaxy (contexto semântico)
Português funciona bem (o modelo é multilingual)

Mas ainda errava em casos sutis:

iPhone 17 Pro vs iPhone 17 Pro Max, similaridade 0.91, mas são produtos diferentes
Cores e capacidades diferentes eram agrupadas

Embeddings resolvem bem o "óbvio". Casos sutis precisavam de algo mais inteligente.

⚙️ Solução final: pipeline híbrido em 2 fases

Fase 1, Clustering semântico (offline, grátis)

Calcula embeddings de todos os produtos
Agrupa por similaridade > 0.80 usando clustering aglomerativo
Reduz os produtos de 200k para produtos pré agrupados (batches menores para o LLM)
Passa cada grupo para o LLM, sem exceção

Fase 2, LLM (validação total)

Manda todos os grupos para Gemini/Claude/Ollama em paralelo
O LLM responde: "estes formam um grupo? qual é o nome canônico?"
Valida semântica (cor != modelo) e nomeia canonicamente
Salva metadata: quais LLMs concordaram com cada grupo

💰 Ganho: o clustering reduz o volume em 40x antes de chamar o LLM. O custo de API cai porque processamos batches menores, em vez de comparar 200k produtos pairwise.

🗳️ A sacada do consenso multi-LLM

Mesmo assim, LLM erra. Gemini às vezes inventa modelos. Llama foca demais em palavra-chave. Cada um tem um viés diferente.

Solução: rodar várias LLMs em paralelo e comparar as respostas.

lnp get_suggest_produtos_ai \
  --model gemini/gemini-2.5-flash-lite \
  --model groq/llama-3.3-70b-versatile \
  --model anthropic/claude-haiku-4-5 \
  --model ollama/qwen2.5:7b

Cada produto agrupado guarda quais LLMs concordaram com a sugestão:

{
  "nome_sugerido": "iPhone 17 Pro Max 256GB",
  "descricao": "Experimente a combinação perfeita de design e performance com o iPhone 17 Pro Max de 256GB. Capture momentos inesquecíveis com sua câmera de ponta e desfrute de velocidade excepcional para aplicativos e jogos. Com amplo espaço de armazenamento, você terá liberdade para guardar todos os seus arquivos importantes. Seu display vibrante e recursos avançados garantem uma experiência de usuário imersiva e produtiva. Descubra a inovação Apple em suas mãos.",
  "produtos": [
    { "id": 12345, "llms": ["gemini", "claude", "llama"] },
    { "id": 67890, "llms": ["gemini"] }
    ...
  ],
  "categoria_id": 35,
  "categoria_nome": "Placa de Vídeo",
  "marca_id": 1473,
  "marca_nome": "Zotac",
  "confianca": 0.95
  ...
  "llms": [
      "gemini", "claude", "llama"
  ]
}

Foi desenvolvido um comando que basicamente faz a busca no banco de sugestões de grupos e faz o agrupamento caso alguns parâmetros estejam contemplados. Além desse comando uma interface no admin foi desenvolvida para agrupar as sugestões.

$ lnp auto_group --min_llms_grupo=4 --min_llms_produto=4 --min_lojas=2 --min_produtos=2 --images=3 --add --update --category='notebook'

O comando acima, busca nas sugestões obtidas antes onde: --min_llms_grupo=4 - no mínimo 4 llms concordam com o grupo sugerido. --min_llms_produto=4 - no mínimo 4 llms concordam com os produtos sugeridos nos grupos. --min_lojas=2 - deve ter no mínimo 2 lojas no grupo --min_produtos=2 - deve ter no mínimo 2 produtos no grupo --images=3 - faz o download das imagens sugeridas pela api do serper caso o grupo esteja em 2 lojas e 2 produtos no mínimo. --add --update - Adiciona os novos grupos e atualiza os existentes --category - Filtra a categoria

━━━ Categoria: Notebook ━━━
  ▸ Marca: Apple
    [UPDATE] [MacBook Air M4 13.6 16GB 256GB] llms_grupo=8 | produtos=12 - Atual=12 - Novos=+0 [≥4 llms] | 📷 10
    [UPDATE] [MacBook Air M4 15.3 16GB 512GB] llms_grupo=6 | produtos=6 - Atual=6 - Novos=+0 [≥4 llms] | 📷 10
    [SKIP]   [Macbook Air M4 15.3" 24GB/512GB] sem produtos após filtro llms_produto
    [NOVO]   [Macbook Air M5 16Gb/512Gb 13"] llms_grupo=6 | produtos=4 [≥4 llms] | 📷 10
------------------------------------------------------------
Resumo por categoria:
  Notebook  total=4  novos=1  update=2  skip=1
------------------------------------------------------------
Resumo por marca:
  Apple    total=4  novos=1  update=2  skip=1

Isso reduziu drasticamente meu tempo de revisão. Em vez de olhar 4000 grupos um por um, eu foco nos casos em que as LLMs discordam entre si, exatamente os casos ambíguos em que minha decisão importa.