ShopBot AI
Servidor MCP de atención al cliente con IA que permite consultar el estado de pedidos y realizar búsquedas en la base de conocimiento impulsada por RAG para tiendas de comercio electrónico.
Documentación
ShopBot AI — Agente de soporte de comercio electrónico impulsado por MCP
ShopBot AI es un chatbot de soporte de comercio electrónico que construí para explorar hasta dónde se puede llevar a los LLM cuando están conectados a sistemas reales como bases de datos y canalizaciones de recuperación.
En lugar de depender solo de respuestas basadas en indicaciones, el bot puede realmente:
- consultar pedidos reales almacenados en MySQL
- buscar en una base de conocimientos mediante embeddings (FAISS)
- decidir cuándo debe usar herramientas frente a cuándo simplemente responder con normalidad
La idea era simple:
un chatbot que no alucine cuando importa (como el estado de un pedido).
🔗 Demo en vivo: https://shopbot-ai-os4z.onrender.com
Por qué lo construí
La mayoría de las demos de chatbots parecen impresionantes al principio, pero fallan rápidamente cuando preguntas:
- "¿Dónde está mi pedido?"
- "¿Cuál es exactamente su política de reembolso?"
- "¿Este producto está disponible?"
Normalmente responden con confianza… incluso cuando no deberían.
Quería construir algo más parecido a cómo debería comportarse un sistema de soporte real:
- si es factual → consultar una base de datos
- si es semántico → buscar en la base de conocimientos
- de lo contrario → dejar que el modelo responda con normalidad
Esto me llevó a combinar RAG, llamadas a herramientas y lógica de enrutamiento en un solo sistema.
Cómo funciona
Mensaje del usuario ↓ API Flask ↓ Gemini decide la intención (enrutar consulta) ↓ Capa de herramientas MCP ├── Herramienta MySQL → datos de pedidos / clientes └── Herramienta FAISS → recuperación de preguntas frecuentes / políticas ↓ ↓ Respuesta final al usuario
Decisiones clave de diseño (y por qué las tomé)
MCP en lugar de llamadas directas a funciones
Usé MCP porque no quería que la lógica de las herramientas se mezclara directamente con la capa del LLM. Mantiene las cosas modulares, de modo que añadir una nueva herramienta más adelante no requiera reescribir toda la lógica de enrutamiento.
FAISS en lugar de una base de datos vectorial alojada
Opté por FAISS principalmente porque quería que todo se ejecutara localmente sin costes adicionales de infraestructura. Mantiene el proyecto autocontenido y más fácil de demostrar.
Gemini para el enrutamiento
Gemini solo se usa para decidir qué tipo de pregunta es, no para almacenar ninguna "verdad". Esa separación fue intencional para reducir el riesgo de alucinaciones.
Flask en lugar de FastAPI
Esto comenzó como un prototipo, así que Flask simplemente fue más rápido para iterar. Prioricé construir el sistema sobre la perfección del framework.
Lo que aprendí al construir esto
- El uso de herramientas importa más que la ingeniería de indicaciones para la fiabilidad en el mundo real
- RAG por sí solo no es suficiente a menos que la recuperación esté bien delimitada
- Una capa de enrutamiento simple mejora la precisión más de lo esperado
- La mayoría de los "problemas de chatbots con IA" son en realidad problemas de diseño de sistemas