ShopBot AI
Servidor MCP de suporte ao cliente com IA, consulta de status de pedidos e busca em base de conhecimento baseada em RAG para lojas de e-commerce.
Documentação
ShopBot AI — Agente de Suporte de E-commerce com MCP
ShopBot AI é um chatbot de suporte de e-commerce que construí para explorar até onde você pode levar LLMs quando eles estão conectados a sistemas reais como bancos de dados e pipelines de recuperação.
Em vez de depender apenas de respostas baseadas em prompts, o bot pode na verdade:
- verificar pedidos reais armazenados no MySQL
- pesquisar uma base de conhecimento usando embeddings (FAISS)
- decidir quando deve usar ferramentas vs quando deve apenas responder normalmente
A ideia era simples:
um chatbot que não alucina quando importa (como status do pedido).
🔗 Demonstração ao vivo: https://shopbot-ai-os4z.onrender.com
Por que construí isso
A maioria das demonstrações de chatbot parecem impressionantes no início, mas quebram rapidamente quando você pergunta:
- “Onde está meu pedido?”
- “Qual é exatamente a sua política de reembolso?”
- “Este produto está em estoque?”
Eles geralmente respondem com confiança… mesmo quando não deveriam.
Eu queria construir algo mais próximo de como um sistema de suporte real deveria se comportar:
- se for factual → consultar um banco de dados
- se for semântico → pesquisar na base de conhecimento
- caso contrário → deixar o modelo responder normalmente
Isso me levou a combinar RAG, chamada de ferramentas e lógica de roteamento em um único sistema.
Como funciona
Mensagem do usuário ↓ Flask API ↓ Gemini decide a intenção (rota da consulta) ↓ Camada de ferramentas MCP ├── Ferramenta MySQL → dados de pedido / cliente └── Ferramenta FAISS → recuperação de FAQ / políticas ↓ ↓ Resposta final ao usuário
Principais escolhas de design (e por que as fiz)
MCP em vez de chamadas diretas de função
Usei MCP porque não queria que a lógica das ferramentas fosse misturada diretamente na camada LLM. Isso mantém as coisas modulares, então adicionar uma nova ferramenta depois não exige reescrever toda a lógica de roteamento.
FAISS em vez de um banco de vetores hospedado
Optei pelo FAISS principalmente porque queria que tudo rodasse localmente sem custos extras de infraestrutura. Isso mantém o projeto autocontido e mais fácil de demonstrar.
Gemini para roteamento
O Gemini é usado apenas para decidir que tipo de pergunta é essa, não para armazenar nenhuma “verdade”. Essa separação foi intencional para reduzir o risco de alucinação.
Flask em vez de FastAPI
Isso começou como um protótipo, então o Flask foi simplesmente mais rápido para iterar. Priorizei construir o sistema em vez da perfeição do framework.
O que aprendi construindo isso
- O uso de ferramentas importa mais do que engenharia de prompt para confiabilidade no mundo real
- RAG sozinho não é suficiente a menos que a recuperação seja bem delimitada
- Uma camada de roteamento simples melhora a precisão mais do que o esperado
- A maioria dos “problemas de chatbot de IA” são, na verdade, problemas de design de sistema