ShopYA — Marketplace SaaS
Ingeniería de producto y arquitectura distribuida de marketplace, extendidas con un asistente RAG integrado en producción para descubrimiento conversacional.
Líder de Producto y Tecnología
Equipo multidisciplinario de aproximadamente 9–10 personas
- Servicios orientados a dominios
- RAG en producción con OpenAI + pgvector
- Consistencia entre servicios y aislamiento entre tenants
Problema
Los pequeños negocios de Argentina necesitaban una forma accesible de crear y operar una tienda online. ShopYA combinó tiendas individuales con descubrimiento dentro de un marketplace y utilizó planes de suscripción en lugar de cobrar comisiones por cada venta.
Contexto y responsabilidad
Creé ShopYA desde cero y lideré el proyecto de manera sostenida como Líder de Producto y Tecnología. Fui responsable de la arquitectura y la dirección técnica, y participé en decisiones y compensaciones de producto y negocio dentro de un equipo multidisciplinario de aproximadamente 9–10 personas.
Alcance del sistema
- Autenticación y acceso aislado por tenant
- Tiendas de vendedores, catálogo y descubrimiento en el marketplace
- Pedidos, pagos y operaciones de vendedores
- Planes de suscripción y límites
- Envíos e integraciones con transportistas
- Mensajería, notificaciones y funciones en tiempo real
- Incorporación, aprobación y analíticas para vendedores
Arquitectura
Una aplicación web en Next.js se conectaba con servicios en NestJS y TypeScript organizados alrededor de autenticación, catálogo, pedidos, pagos, suscripciones, envíos y mensajería. PostgreSQL almacenaba el núcleo transaccional y relacional del marketplace; Firestore resolvía necesidades orientadas a documentos y en tiempo real, como el chat entre compradores y vendedores y las notificaciones. El aislamiento entre tenants atravesaba todos los dominios en lugar de pertenecer a un único servicio.
- Aplicación web en Next.js
- Servicios de dominio en NestJS
- TypeScript
- Núcleo transaccional en PostgreSQL
- Funciones en tiempo real con Firestore
Desafío de ingeniería
Mantener coherente el estado distribuido del marketplace
El desafío principal fue mantener un estado de negocio consistente entre dominios del marketplace desplegados de manera independiente, preservando el aislamiento entre tenants y evitando estados inválidos entre dominios. Un mismo flujo podía atravesar pedidos, pagos, suscripciones, envíos y operaciones de vendedores, por lo que los límites de servicio debían seguir siendo claros sin tratar cada dominio como una funcionalidad aislada.
Decisiones y fundamentos
Límites de servicio orientados a dominios
- Decisión
- Separar autenticación, catálogo, pedidos, pagos, suscripciones, envíos y mensajería mediante límites explícitos de servicio y dominio.
- Fundamento
- Los límites representaban responsabilidades de negocio diferentes, superficies de integración, necesidades de despliegue independiente y el crecimiento esperado del producto. Reducían el acoplamiento y aclaraban la propiedad de las reglas de negocio.
- Compensaciones
- La separación introdujo mantenimiento de contratos entre servicios, coordinación de despliegues, mayores necesidades de observabilidad, más modos de falla, trabajo de consistencia entre servicios y una sobrecarga operativa superior a la de un monolito modular.
PostgreSQL y Firestore según la carga de trabajo
- Decisión
- Usar PostgreSQL para el núcleo transaccional y relacional del marketplace, y Firestore para necesidades documentales y en tiempo real como chat y notificaciones.
- Fundamento
- Las dos bases respondían a características distintas: el estado relacional del comercio requería un modelo transaccional estructurado, mientras que la mensajería y las notificaciones se beneficiaban del acceso documental en tiempo real.
- Compensaciones
- Usar ambos modelos de persistencia aumentó la complejidad operativa y conceptual. Los flujos entre dominios requerían contratos y reglas de propiedad deliberados para evitar estados de negocio inconsistentes; el diseño no implicaba una base de datos separada por servicio.
Contexto de producción
ShopYA se desplegó como un producto real. Más de 300 tiendas fueron incorporadas o cargadas en la plataforma. La plataforma alcanzó un nivel de desarrollo técnico mayor que su tracción comercial y la adquisición de clientes terminó convirtiéndose en la principal restricción del producto.
Resultado e impacto
Se entregó el marketplace multitienda con sus principales dominios operativos. El trabajo validó el alcance técnico y reforzó una lección de liderazgo de producto: la solidez técnica y la arquitectura no sustituyen una estrategia de adquisición validada.
Tecnologías
- TypeScript
- Node.js
- Next.js
- NestJS
- OpenAI SDK
- gpt-4o-mini
- text-embedding-3-small
- Supabase
- PostgreSQL / pgvector
- Firestore
- Server-Sent Events
- Winston / Loki
- PM2
- Vercel
Integraciones
- Andreani
- OCA
Diagrama de arquitectura
IA aplicada: Asistente RAG para el marketplace
Un asistente RAG integrado en producción que fundamenta el descubrimiento dentro del marketplace en el catálogo de ShopYA y conocimiento curado de la plataforma, en lugar de depender solo de la memoria del modelo.
- RAG con OpenAI + pgvector
- Reescritura de consultas multivuelta
- Suite de evaluación versionada con 36 casos
Problema
Los visitantes anónimos del marketplace necesitaban una forma conversacional de descubrir productos, categorías y tiendas, hacer preguntas de seguimiento, aprender mediante guías curadas de ShopYA y navegar hacia páginas relevantes. Una experiencia basada solo en el modelo no reflejaría de forma confiable un catálogo cambiante ni la orientación específica de ShopYA.
Por qué RAG
El inventario del marketplace y la orientación de la plataforma cambian con el tiempo, por lo que las respuestas debían provenir del catálogo y del conocimiento gestionados por ShopYA, no de la memoria preentrenada del modelo. La recuperación aporta ese contexto cambiante y mantiene la generación enfocada en descubrimiento y navegación.
Contexto y responsabilidad
Diseñé e implementé el asistente de IA como parte de ShopYA, desde el formateo del conocimiento y la recuperación vectorial hasta la composición del prompt, el streaming de la API, la integración con la tienda y la posterior suite de evaluación. Esta sección distingue ese trabajo de IA aplicada dentro de mi liderazgo más amplio de producto y arquitectura en la plataforma ShopYA.
Alcance del sistema
- Descubrimiento anónimo de productos, categorías y tiendas
- Orientación mediante conocimiento curado de la plataforma
- Historial de conversación y reescritura opcional de preguntas de seguimiento
- Recuperación vectorial sobre contexto del marketplace y la plataforma
- Respuestas transmitidas, enlaces al marketplace y sugerencias de respuesta rápida
- Registro de chats, tokens y costo estimado
- Orientación de solo lectura, sin capacidad de modificar el comercio
Arquitectura
La ruta de solicitud conecta un widget de chat en Next.js con una API NestJS que transporta el historial, puede reescribir una pregunta de seguimiento como consulta independiente, crea un embedding con OpenAI y recupera los vectores más similares desde Supabase/PostgreSQL. El contexto recuperado se combina con instrucciones, ejemplos, historial y el mensaje actual para gpt-4o-mini; la respuesta llega a la tienda mediante Server-Sent Events y se registra el uso. Firestore continúa siendo la fuente autoritativa de los datos del marketplace y del conocimiento de la plataforma, mientras Supabase con pgvector almacena datos derivados para la recuperación de IA.
- Widget de chat en Next.js
- Orquestación en NestJS
- Reescritura de consultas según la conversación
- Embeddings y generación con OpenAI
- Supabase / PostgreSQL pgvector
- Server-Sent Events
- Observabilidad con Winston / Loki
Diagrama de arquitectura
Flujo de IA
La ejecución sigue una secuencia acotada de recuperación y generación. Puede mejorar la consulta de recuperación para una pregunta de seguimiento, pero no entra en un bucle autónomo ni invoca herramientas de negocio.
- Recibir el mensaje del visitante y el historial reciente de la conversación.
- Reescribir una pregunta de seguimiento contextual como consulta independiente cuando sea necesario.
- Crear el embedding de la consulta con text-embedding-3-small.
- Ejecutar recuperación por similitud coseno en pgvector con umbral 0,4 y top-k 10.
- Insertar el texto recuperado del marketplace y la plataforma en el contexto final.
- Generar con gpt-4o-mini y temperatura 0,1.
- Transmitir la respuesta mediante SSE y registrar chat, tokens y costo estimado.
Estrategia de prompt y contexto
El prompt define el alcance, el tono, el formato para el marketplace, orientación contra alucinaciones, rechazo de inyecciones de prompt, comportamiento explícito sin resultados y sintaxis para respuestas rápidas. El contexto final se arma en este orden deliberado:
- Instrucciones del sistema
- Contexto recuperado del marketplace y conocimiento de la plataforma
- Ejemplos estáticos few-shot
- Historial de conversación
- Mensaje actual del usuario
Contexto de producción
El asistente está integrado en la arquitectura real del marketplace ShopYA: una tienda Next.js en Vercel, un backend NestJS operado con PM2 y registros mediante Winston/Loki. La implementación usa gpt-4o-mini para generación conversacional y text-embedding-3-small para recuperación, equilibrando una experiencia responsiva con un costo de inferencia práctico. Es una aplicación RAG para descubrimiento, no un sistema autónomo ni operativo.
Decisiones y fundamentos
Usar RAG en lugar de respuestas basadas solo en el modelo
- Decisión
- Recuperar contexto del catálogo de ShopYA y de la plataforma antes de generar respuestas de descubrimiento.
- Fundamento
- Los datos cambiantes del marketplace y la orientación específica de ShopYA deben provenir de contenido mantenido, no solo de la memoria del modelo.
- Compensaciones
- El sistema requiere sincronización de vectores y la calidad de recuperación agrega otro modo de falla.
Mantener Firestore autoritativo y los vectores derivados
- Decisión
- Tratar los registros del marketplace y del conocimiento de la plataforma en Firestore como datos fuente, y las filas pgvector en Supabase como datos derivados para IA.
- Fundamento
- El índice de IA no debe convertirse en la fuente de verdad de productos, tiendas, categorías ni orientación de la plataforma.
- Compensaciones
- Los almacenes autoritativo y derivado deben sincronizarse cuando cambia el contenido fuente.
Mantener el modelo en modo de solo lectura
- Decisión
- Limitar el asistente a recomendaciones, explicaciones, enlaces y sugerencias de seguimiento, sin capacidades de modificación del negocio.
- Fundamento
- El descubrimiento y la orientación no justificaban exponer al modelo modificaciones de pedidos, productos, tiendas, reembolsos o pagos.
- Compensaciones
- El asistente puede guiar al visitante hacia el próximo paso, pero no completar acciones operativas.
Transmitir respuestas mediante SSE
- Decisión
- Enviar el texto generado de forma incremental desde la API NestJS hacia la tienda.
- Fundamento
- El streaming mejora la latencia percibida durante el descubrimiento conversacional sin inventar cifras de latencia.
- Compensaciones
- Las respuestas parciales y los errores posteriores al inicio de la transmisión requieren un manejo más cuidadoso en cliente y servidor.
Agregar evaluación antes de optimizar la recuperación
- Decisión
- Crear un dataset versionado y una suite de evaluación determinística antes de introducir cambios como chunking o reranking.
- Fundamento
- Los cambios futuros deben compararse con casos explícitos en lugar de ajustarse por impresiones subjetivas o complejidad impulsada por frameworks.
- Compensaciones
- La infraestructura de evaluación agrega mantenimiento y establece un método de comparación; por sí sola no mejora la calidad del modelo.
Evaluación
Luego agregué una suite reproducible de evaluación de IA para que los cambios futuros del RAG puedan compararse con casos explícitos en lugar de ajustarse por impresiones subjetivas. El dataset versionado contiene 36 casos y las pruebas determinísticas del evaluador pasan.
Cobertura de casos
- Descubrimiento de productos, tiendas y categorías
- Conocimiento de la plataforma
- Reescritura de seguimiento y recuperación vacía
- Solicitudes no admitidas e inyección de prompt
Métricas disponibles
- Tasa de aciertos de recuperación y rango recíproco medio
- Corrección sin resultados y comportamiento de reescritura
- Comportamiento fundamentado y afirmaciones prohibidas
- Enlaces inválidos y fallas del contrato de respuesta
- Comportamiento ante inyección de prompt y datos de tokens/costo
No se informa una línea base de calidad con proveedores. Las credenciales aisladas de evaluación no se configuraron intencionalmente, por lo que no existen porcentajes de recuperación o generación para afirmar.
Limitaciones y próximos interrogantes
La primera versión en producción favoreció deliberadamente una recuperación simple y un alcance acotado. Estas restricciones mantienen el sistema comprensible y hacen explícitos los próximos interrogantes de ingeniería.
- Un vector por entidad o artículo, sin chunking ni reranking
- Sin citas de fuentes ni una capa de verificación de procedencia
- Salida Markdown libre en lugar de una salida estructurada
- Sin herramientas del modelo, bucle autónomo ni modificaciones del negocio
- Observabilidad específica de IA limitada al registro de chats, tokens, costo y aplicación
- Suite de evaluación implementada, pero sin línea base ejecutada con proveedores
Los próximos cambios de recuperación —como chunking o reranking— deberían justificarse mediante fallas medidas en una línea base controlada, no agregarse de forma preventiva.
Resultado e impacto
Entregué un asistente de descubrimiento de solo lectura, integrado en producción y fundamentado en contenido del marketplace y la plataforma ShopYA, además de una base de evaluación versionada para comparar futuros cambios de recuperación y prompt sin inventar resultados de calidad.
Ver el proyecto en funcionamiento
Visitar sitio web