Portafolio técnico

Sistemas de IA y
machine learning aplicado

Ocho sistemas de machine learning y automatización con inteligencia artificial, construidos para resolver problemas concretos de negocio en la industria de restaurantes y delivery. La mayoría opera a diario.

Cada proyecto se presenta con su objetivo, lo que se construyó y el aprendizaje que dejó. Dos conclusiones se repiten en todos: un modelo de lenguaje no debe tener la última palabra sobre algo con consecuencias reales, y un análisis que el destinatario no entiende no sirvió de nada.

Sobre los datos. Varios de estos sistemas se construyeron para un empleador y para clientes reales. Por eso aquí se describe únicamente la arquitectura: ninguna cifra de negocio, ningún identificador de cliente y ningún esquema interno de base de datos sale de su origen. El código correspondiente vive en un repositorio privado y se comparte a solicitud.
01 Orquestación de agentes
01

Automatización de presentaciones de negocio para clientes Producción

Objetivo

Cada revisión de negocio con un cliente se armaba a mano: extraer los datos, interpretarlos, decidir el mensaje, construir las gráficas y verificar cada cifra. El objetivo fue automatizar ese proceso completo sin perder calidad, y evitar los dos errores que más cuestan credibilidad: una cifra equivocada y una lámina que el cliente no entiende.

Qué se construyó

Un sistema donde 22 agentes de inteligencia artificial se reparten el trabajo por especialidad: unos consultan la base de datos, otros diagnostican el desempeño, definen la recomendación, eligen el tipo de gráfica y arman el archivo final. Agentes distintos, que no participaron en construirla, revisan la presentación terminada en busca de contradicciones. Antes de cualquier entrega corre un validador automático en Python sobre el archivo ya generado: si encuentra jerga interna, siglas sin explicar, comparaciones sin año o cifras ilegibles, bloquea la entrega.

Aprendizaje

La calidad no se logró mejorando las instrucciones que se le dan al modelo, sino sacándole la decisión final. Un modelo genera texto plausible, y lo plausible no es lo mismo que lo correcto. Cuando las reglas de calidad pasaron de ser recomendaciones a ser código capaz de rechazar el archivo, los errores dejaron de llegar al cliente.

Claude Agent SDKSistemas multi-agente Validación automatizadaPython python-pptxSQL
02

Sistema de pronóstico de ventas con 10 agentes Producción

Objetivo

Pronosticar ventas a partir de los datos tal como llegan en la realidad: una hoja de cálculo, un export del sistema o un PDF, sin exigir que nadie los prepare ni sepa de estadística para usarlos.

Qué se construyó

Un sistema de 10 agentes donde cada uno tiene una función: leer el archivo, detectar qué columna es la venta y cuál la fecha, evaluar si la historia alcanza para pronosticar, y correr cuatro modelos de pronóstico en paralelo (SARIMAX, Prophet, XGBoost y Random Forest) que compiten entre sí sobre datos que ninguno vio durante el entrenamiento. Gana el de menor error, y un agente final traduce el resultado a una recomendación escrita en lenguaje de negocio.

Aprendizaje

Ningún modelo gana siempre: con datos reales, el mejor cambia según la serie. Por eso el sistema compara en cada corrida en lugar de casarse con un algoritmo. Y el agente que evalúa si los datos alcanzan resultó tan valioso como los modelos: decir "con esta historia no se puede pronosticar de forma confiable" es una mejor respuesta que un pronóstico bonito construido sobre nada.

SARIMAXProphet XGBoostRandom Forest FastAPIReact
02 Machine learning y marketing science
03

Marketing Mix Modeling: medir qué inversión sí genera venta Producción

Objetivo

"Invertimos en descuentos y publicidad y la venta subió" no demuestra nada: la inversión coincide con la estacionalidad y con las tiendas que ya venían creciendo. El objetivo fue medir cuánta venta trajo realmente cada tipo de inversión, en qué punto deja de rendir cada peso adicional, y cómo repartir mejor el mismo presupuesto.

Qué se construyó

Un modelo econométrico sobre la historia semanal de cada tienda que separa el efecto de la inversión del efecto del tamaño de la tienda, la tendencia y la temporada. Incorpora dos comportamientos reales del marketing: la inversión de una semana sigue trabajando las siguientes, y todo canal se satura. Reporta cada efecto con su rango de confianza, y el resultado pasa por seis validaciones automáticas; si alguna falla, el modelo no se publica.

Aprendizaje

En este problema nadie conoce la respuesta correcta, así que un modelo convincentemente equivocado se ve idéntico a uno correcto. La solución fue crear datos artificiales donde la respuesta se conoce porque se plantó a propósito, y exigir que el modelo la recupere antes de confiar en él con datos reales. El otro aprendizaje: no reportar estadísticas que técnicamente no aplican; dar la incertidumbre real vale más que aparentar precisión.

Econometría aplicadaAdstock Curvas de saturaciónBootstrap scikit-learnNumPy
04

ML Studio: machine learning para quien no sabe de machine learning Proyecto personal

Objetivo

Las herramientas de análisis automático siguen preguntando qué variable predecir y qué tipo de problema es, exactamente lo que una persona de negocio no sabe contestar. El objetivo fue que el usuario solo suba su archivo y reciba el análisis, sin configurar nada.

Qué se construyó

Una plataforma web completa (interfaz en React, motor en Python) que recibe cualquier archivo CSV, deduce el tipo de cada columna, identifica qué conviene predecir y elige la técnica correcta entre clasificación, regresión, agrupación de casos similares o pronóstico en el tiempo. Entrena varios modelos, compara su desempeño, y entrega gráficas y recomendaciones escritas en español, con los grupos detectados descritos por sus características en lugar de numerados.

Aprendizaje

Lo difícil no fue entrenar los modelos, sino todo lo que pasa antes y después: deducir la intención a partir de datos imperfectos y traducir el resultado a algo accionable. Un archivo real siempre llega con columnas mezcladas, huecos y formatos rotos; cada error tiene que regresar como mensaje comprensible, porque el usuario de esta herramienta no puede depurar un error técnico.

scikit-learnFastAPI ReactViteRecharts
05

Análisis de retorno publicitario y segmentación de tiendas Producción

Objetivo

Un ranking de tiendas por retorno publicitario no dice qué hacer: dos tiendas con el mismo retorno pueden necesitar acciones opuestas, porque a una le falta exposición y la otra recibe visitas de sobra pero no las convierte en pedidos. El objetivo fue pasar del ranking a grupos de tiendas con un diagnóstico accionable cada uno.

Qué se construyó

Un dashboard que recibe los reportes de campañas publicitarias tal como los exporta la plataforma, calcula las métricas de retorno y agrupa las tiendas por comportamiento con K-Means, validando estadísticamente cuántos grupos existen de verdad. Cada grupo se describe por lo que lo distingue ("mucho tráfico, conversión débil") en lugar de un número de cluster. El sistema no depende de los nombres de columna del reporte: los reconoce por alias, así que sigue funcionando cuando la plataforma cambia su plantilla.

Aprendizaje

La segmentación solo se volvió útil cuando cada grupo recibió nombre y diagnóstico: "Cluster 3" no significa nada para quien decide, "convierte mal con tráfico de sobra" sí. Y en sistemas que consumen archivos ajenos, asumir la estructura es fabricar fallas futuras: el formato de entrada siempre termina cambiando.

K-MeansValidación de clusters PCAFastAPIReact
03 Producto y herramientas
06

RecetaFlow: de la venta semanal a la orden de compra Cliente real

Objetivo

En un restaurante, calcular la compra de insumos a mano cada semana consume horas y produce errores en las dos direcciones: comprar de más desperdicia, comprar de menos deja de vender. El objetivo fue convertir el reporte semanal de ventas en una orden de compra precisa, de forma automática.

Qué se construyó

Un sistema que cruza cada producto vendido contra su receta para calcular los ingredientes exactos, convierte unidades (la receta pide gramos, el proveedor vende cajas de 5 kilos) y arma la orden de compra final en Excel o PDF. Un módulo de inteligencia artificial sugiere ajustes por temporada, pero solo sugiere: el cálculo es aritmética verificable y ningún ajuste se aplica sin confirmación del usuario. Todo producto vendido que no tiene receta registrada se reporta como alerta visible.

Aprendizaje

Donde hay dinero de por medio, la inteligencia artificial aconseja y la aritmética decide: un modelo de lenguaje no debe calcular cuánta carne comprar. Y los errores silenciosos son los caros: omitir sin avisar un producto sin receta produce una orden de compra que se ve completa y llega corta. Preferir la alerta incómoda al silencio fue la decisión de diseño más importante del sistema.

PythonPolars FastAPIAPI de Anthropic React
07

Escriba: transcripción de reuniones sin subir el audio a internet Uso diario

Objetivo

Los servicios de transcripción de reuniones envían el audio a sus servidores, y en conversaciones comerciales con clientes esa es una decisión de confidencialidad que nadie en la sala aprobó. El objetivo fue tener transcripción y minuta automáticas con el audio procesado íntegramente en la propia computadora.

Qué se construyó

Una aplicación de macOS que transcribe en vivo con Whisper corriendo localmente. Captura el micrófono y el audio de la reunión por canales separados, para distinguir lo dicho por cada lado sin adivinar. Un detector de voz identifica cuándo se habla y recorta frases completas, conservando una fracción de segundo previa para que ninguna palabra llegue cortada. Al terminar genera la minuta: resumen, acuerdos, pendientes y borrador de correo de seguimiento.

Aprendizaje

En audio, la diferencia entre demo y herramienta está en detalles de ingeniería que no se ven: cuándo cortar cada frase, cuánto contexto conservar, cómo procesar solo la voz y no el silencio. Y una restricción dura declarada desde el inicio (el audio no sale de la máquina) simplifica todas las decisiones posteriores en lugar de complicarlas: cada componente se eligió con ese criterio ya resuelto.

Whisper localDetección de voz ONNX RuntimePython Swift
08

JobHunter: automatización de búsqueda de empleo con reglas de honestidad Uso diario

Objetivo

Automatizar la búsqueda de vacantes y la adaptación del CV a cada una, con una restricción central: el sistema no puede inventar nada. Un modelo al que se le pide adaptar un CV tiende a exagerar (un título de puesto que suena mejor, una cifra que nadie midió), y en un proceso de reclutamiento eso se descubre y descalifica.

Qué se construyó

Una tubería que busca vacantes en varias fuentes a la vez, descarta las ya vistas y califica qué tan bien empata cada una con el perfil real. El generador de CV adapta el orden y el énfasis hacia cada vacante, pero sus reglas de honestidad son código, no instrucciones al modelo: el título del puesto no se puede alterar, una habilidad que no se tiene jamás se agrega, y el archivo se verifica antes de emitirse (incluyendo que un sistema de reclutamiento pueda leer su texto correctamente). Si algo falla, el generador elimina su propio archivo en lugar de entregarlo.

Aprendizaje

Pedirle honestidad a un modelo en las instrucciones no basta, porque su tendencia es complacer la tarea. La honestidad confiable se construye fuera del modelo, como validación que no se puede negociar. Es el mismo principio del resto de estos sistemas, aplicado a un caso donde el costo de una exageración es personal: la credibilidad propia.

Automatización con LLMClaude Code Validación de documentosPython

¿Quieres ver el código?

El repositorio con la implementación completa (motor de MMM con su suite de pruebas, las compuertas del pipeline de agentes, el backend de AutoML y el resto) es privado para proteger el contexto en el que se construyó. El acceso se comparte a solicitud.

Solicitar acceso