Prueba Técnica: Full-Stack AI Engineer
1. Contexto del DesafÃo
- En VIVETORI buscamos ingenieros que dominen tanto el desarrollo tradicional como las nuevas fronteras de la Inteligencia Artificial.
- Tu objetivo es construir un "AI-Powered Support Co-Pilot": un sistema capaz de recibir tickets de soporte, procesarlos mediante agentes de IA para categorizarlos y analizar su sentimiento, y visualizarlos en tiempo real en un dashboard.
2. Requerimientos Técnicos
2.1. Base de Datos (Supabase)
Ver paso a paso para 2.1 Base de Datos (Supabase)
- Configura una tabla tickets en Supabase con los siguientes campos:
- id (UUID, Primary Key)
- created_at (Timestamp)
- description (Text - El contenido del ticket)
- category (Text/Enum - Ej: Técnico, Facturación, Comercial)
- sentiment (Text - Ej: Positivo, Neutral, Negativo)
- processed (Boolean - Default: false)
- Entregable: Un archivo setup.sql con el esquema de la tabla y cualquier polÃtica RLS necesaria.
2.2. Microservicio de IA (Python + FastAPI)
Ver paso a paso para 2.2 Microservicio de IA
- Crea una API en Python utilizando FastAPI y LangChain.
- Implementa un endpoint POST /process-ticket que:
- Reciba el texto de un ticket.
- Utilice un modelo de lenguaje (LLM via LangChain/Hugging Face) para extraer la categorÃa y el sentimiento en formato JSON estructurado.
- Actualice la fila correspondiente en Supabase marcándola como processed: true.
- Despliegue: Debes desplegar este servicio en una plataforma gratuita como Render.com, Vercel o Railway.app.
- Entregable: La URL pública de la API y el código fuente.
2.3. Automatización Low-Code (n8n)
Ver paso a paso para 2.3 Automatizacion Low-Code (n8n)
- Crea un flujo en n8n que:
- Se active mediante un Webhook o un trigger de "Nueva Fila" en Supabase.
- Consuma tu Microservicio de Python para procesar el ticket.
- Si el sentimiento detectado es "Negativo", el flujo debe disparar una notificación simulada (envÃo de un email).
- (Plus) puedes agregar elementos adicionales a tu flujo que agreguen valor al proyecto.
- Entregable: El archivo .json del flujo exportado.
2.4. Dashboard Frontend (React + TypeScript)
Ver paso a paso para 2.4 Dashboard Frontend
- Desarrolla una interfaz simple con React 18, TypeScript y Vite.
- Requerimientos visuales:
- Usar Tailwind CSS para el diseño.
- Mostrar la lista de tickets consumiendo directamente de Supabase.
- Implementar Realtime (usando los canales de Supabase) para que los tickets aparezcan y se actualicen sin refrescar la página.
- Entregable: La URL de la web desplegada (Vercel/Netlify).
3. Formato de Entrega
- Debes enviar un repositorio de GitHub organizado de la siguiente manera:
- /supabase: Archivo setup.sql.
- /python-api: Código de la API de FastAPI, requirements.txt y Dockerfile (si aplica).
- /n8n-workflow: Archivo .json del flujo.
- /frontend: Código fuente del dashboard.
- En el README del repositorio debe incluirse obligatoriamente:
- URL del Dashboard activo.
- URL de la API de Python activa.
- Breve explicación de la estrategia de Prompt Engineering utilizada para la clasificación.
4. Criterios de Evaluación
- Funcionalidad End-to-End: ¿El sistema realmente procesa un ticket desde que entra hasta que se visualiza?
- Calidad del Microservicio: Manejo de errores en Python, uso de tipos y eficiencia del prompt.
- Dominio de Ecosistema: Integración correcta entre Supabase, n8n y el frontend.
- DevOps Básico: Capacidad de desplegar servicios funcionales en la nube.
5. Información del README
URLs activas
Formato de Entrega (justificación)
/supabase/setup.sql: documenta el esquema y permite recrear la tabla de forma reproducible en Supabase.
/python-api: contiene el microservicio y su configuración para ejecutar y desplegar la API de procesamiento.
/n8n-workflow: guarda el flujo exportado para replicar la automatización sin rehacerlo manualmente.
/frontend: entrega el código del dashboard para build, despliegue y revisión de la UI.
Estrategia de Prompt Engineering (clasificación)
La implementación actual combina dos enfoques para minimizar ambigüedad y errores: (1) un modelo
de sentimiento entrenado para devolver etiquetas estándar (positivo/negativo/neutral) y (2) un
modelo zero-shot para categoría que compara el texto contra un conjunto acotado de labels
predefinidos. Este diseño reduce el espacio de salida y facilita la consistencia entre tickets.
Además, el microservicio mantiene un prompt estricto para escenarios donde se use un LLM
generativo: solicita SOLO JSON válido con category y sentiment, impone formato y restringe
valores permitidos. Esa restricción funciona como contrato de salida, permite parseo seguro y
evita texto extra o narrativo. En conjunto, la estrategia prioriza respuestas estructuradas,
trazables y fáciles de integrar con Supabase y el dashboard.
Glosario
- Prompt engineering: práctica de diseñar instrucciones claras, restricciones y ejemplos para orientar la salida de un modelo. En este proyecto se usa para exigir JSON válido y limitar valores posibles, lo que reduce ambigüedad, mejora la consistencia y facilita la integración con servicios externos.
- Zero-shot: técnica de clasificación donde el modelo no se entrena con datos propios, sino que compara el texto con una lista de categorías dadas. Esto permite adaptar el sistema a nuevos dominios sin reentrenar, aunque requiere etiquetas bien definidas para mantener precisión y coherencia.
- Labels: conjunto acotado de categorías candidatas que el modelo zero-shot evalúa al clasificar. Elegir labels claros y no solapados reduce errores y mejora la interpretabilidad; también funciona como control de calidad para evitar respuestas abiertas o fuera de alcance.
- Sentiment: polaridad emocional del texto que se resume en positivo, negativo o neutral. Se usa para priorizar casos y activar alertas; su valor debe mantenerse estable y comprensible para analítica y reportes, evitando matices que compliquen la automatización.
- LLM: modelo de lenguaje que genera texto a partir de un prompt. En el flujo sirve como alternativa generativa para clasificar si se requiere, pero se restringe su salida con reglas estrictas para que el resultado sea estructurado, verificable y seguro para consumo automático.
- JSON: formato de datos estructurado con claves y valores. Se utiliza como contrato de salida porque es fácil de validar y parsear; exigir JSON válido evita respuestas ambiguas, permite guardar campos directos en base de datos y reduce errores en integraciones.
- Parseo: proceso de leer y validar la respuesta del modelo para extraer campos esperados. En este contexto implica verificar llaves, tipos y valores permitidos; un parseo robusto evita fallos silenciosos y permite manejar errores de forma controlada.
- Supabase: plataforma backend basada en Postgres con APIs y realtime. Aquí almacena tickets y permite consultas desde el dashboard; requiere llaves seguras, control de acceso y una estructura de tabla coherente para que las actualizaciones del microservicio sean confiables.
- Realtime: mecanismo para recibir cambios en tiempo real desde la base de datos. Permite que el dashboard refleje nuevos tickets sin recargar la página; depende de canales y eventos correctos, y requiere que la tabla y permisos permitan emisiones consistentes.