Rafael El Shafie

El problema

Trabajé en el soporte tecnológico del área de onboarding, que apoya a operaciones en la apertura de cuentas y la actualización de datos de clientes. Parte de los tickets recibidos eran dudas de uso u orientación operativa que no requerían una corrección técnica. La propuesta era reunir documentación, orientaciones e información autorizada en una conversación, para que operaciones resolviera sus dudas antes de abrir un ticket y el soporte se concentrara en los casos que requerían investigación.

Mi responsabilidad

Cuando llegué, existía la idea de la solución. Conduje el desarrollo de principio a fin, con la orientación de mi gestor: comprensión del dominio, base de conocimiento, arquitectura, backend, interfaz, integración con IA y bases de datos, pruebas, observabilidad y despliegue. Más adelante, otra pasante se sumó al proyecto, y participé en su orientación y en la organización del trabajo conjunto.

Decisiones que marcaron la diferencia

• Empecé con una base de documentos Markdown en lugar de una base de datos vectorial externa, para concentrar la primera entrega en estructurar el conocimiento y en el funcionamiento de la aplicación dentro del plazo.
• Cuando las pruebas mostraron que los límites de contexto perjudicaban la calidad, y el consumo indicaba margen en el presupuesto, introduje una etapa en la que el modelo de lenguaje selecciona las fuentes relevantes entre los candidatos de la búsqueda por palabras clave. Fue uno de los principales avances del proyecto.
• Probé delegar más etapas del procesamiento a la IA: el costo subió y la calidad bajó. Mantuve una combinación de lógica de aplicación, consultas estructuradas y generación de lenguaje, según lo que necesitaba cada etapa.
• Para consultas recurrentes, creé plantillas SQL parametrizadas en lugar de generar una consulta nueva para cada pregunta, con ejecución de solo lectura en las bases operativas.

Lo que entregué

• Base de conocimiento estandarizada, con categorías, metadatos y referencias cruzadas, y verificaciones de consistencia para encontrar referencias rotas, duplicados y vacíos.
• Chat con historial, feedback estructurado y respuestas mostradas de forma progresiva, además de paneles de administración, seguimiento del consumo y revisión del conocimiento.
• Autenticación corporativa, control de acceso, cuidado con la información sensible en los logs, límites de consumo de IA y observabilidad de cada etapa en Datadog.
• Pruebas de backend, interfaz e integración, conjuntos de preguntas de referencia para evaluar las respuestas y despliegue con Docker, Kubernetes y Azure DevOps, de desarrollo a producción.

Resultado

En una batería interna de casos, los ajustes en la selección de documentos y en la composición del contexto ampliaron de forma notable tanto las preguntas respondidas como las respuestas correctas. El equipo de atención del soporte validó el asistente con situaciones de la rutina, y se entregó en producción. Acompañé el inicio de su uso por parte de operaciones hasta el final de mi pasantía; la reducción de tickets evitables sigue siendo el objetivo de la solución.

Lo que aprendí

La calidad de una solución con IA depende de las decisiones alrededor del modelo: qué información recibe, cómo se consultan los datos, cómo se preserva el contexto y cómo se evalúan los resultados. También aprendí a documentar decisiones y organizar el trabajo para que otras personas pudieran contribuir en el mismo repositorio.

Tecnologías

• Python
• FastAPI
• React
• TypeScript
• PostgreSQL
• MySQL
• RAG
• Text-to-SQL
• Docker
• Kubernetes
• Azure DevOps
• Datadog

Proyectos de esta experiencia

La visión técnica, con arquitectura y tecnologías, está en los detalles de cada proyecto.

• Atlas

La demanda

La búsqueda de inmuebles en Manhattan se hacía manualmente en distintos portales, comparando anuncios, características y precios. El objetivo era reunir esa información en una visión organizada, que facilitara la exploración de los datos y señalara situaciones relevantes, como nuevos anuncios bien puntuados, diferencias de precio y cambios en la disponibilidad de los inmuebles.

Mi contribución y el trabajo en pareja

Desarrollé el proyecto con otro pasante, con la orientación del equipo. La ingesta de datos ya existía, junto con un borrador de la capa de tratamiento: reconstruimos gran parte de esa capa y desarrollamos la preparación para el análisis, las reglas de negocio y las salidas de la solución. Trabajábamos codo a codo, repartiendo las tareas según el conocimiento y el interés de cada uno y decidiendo juntos. Mi responsabilidad más individual fue el dashboard: lo construí en Databricks, inspirándome en el diseño de un dashboard que ya existía y agregando varios recursos. Después, un compañero llevó lo que yo había hecho a la herramienta de visualización propia del banco.

Decisiones que marcaron la diferencia

• Concentrar las fuentes: de los tres portales evaluados, nos quedamos con Zillow y StreetEasy, porque el tercero tenía información menos adecuada al alcance y perjudicaba los filtros.
• Ajustar el alcance: refinamos las categorías de inmuebles según el interés de quien solicitó el proyecto, manteniendo el foco en Manhattan.
• Conciliar sin perder confiabilidad: una fuente completaba a la otra cuando era posible, las divergencias seguían una regla de prioridad y los registros sin calidad suficiente quedaban fuera del análisis.
• Seguir los cambios: guardamos registros anteriores para identificar inmuebles que salían de una fuente y volvían a anunciarse, comparando principalmente el precio.

Resultado

Presentamos el proyecto en inglés a quien lo solicitó, usando el dashboard para mostrar su funcionamiento y sus resultados. Recibimos elogios en la presentación, y la valoración positiva también llegó a nuestros gestores. La entrega centralizó información que antes se consultaba en fuentes distintas y facilitó la comparación. No seguí la evolución del proyecto después de la pasantía.

Lo que aprendí

Reforcé Python y SQL y tuve contacto práctico con Spark y Databricks, la arquitectura Medallion, recursos de AWS y un flujo de notificaciones con mensajería. Aprendí que más datos no siempre mejoran el análisis: fue necesario elegir fuentes, ajustar el alcance y tratar divergencias para llegar a una visión coherente. El trabajo en pareja y la presentación en inglés reforzaron mi capacidad de discutir decisiones y de explicar una solución técnica por su utilidad para el negocio.

Tecnologías

• Python
• SQL
• Apache Spark
• Pandas
• Databricks
• AWS
• RabbitMQ
• Scrum

Proyectos de esta experiencia

La visión técnica, con arquitectura y tecnologías, está en los detalles de cada proyecto.

• Manhattan Real Estate

Aprender construyendo en equipo

Entré en enero de 2024 y empecé por la capacitación de la empresa júnior. La entrega final era un software de gestión desarrollado en equipo: contribuí en distintas partes del backend, con Node.js, TypeScript, NestJS, PostgreSQL y Prisma. Fue mi primera experiencia construyendo software en conjunto y conociendo la organización de una aplicación backend. El proyecto se concluyó como actividad de formación, alrededor de marzo, y no llegó a usarse en operación.

Consultoría: entender la rutina antes de modelar

Después de la capacitación, pasé a trabajar como Consultor de Proyectos. En un trabajo para una industria alimentaria, el sistema de gestión había crecido poco a poco y acumulado funcionalidades que ya no se usaban. Participé en visitas a la fábrica, entrevistas y reuniones con empleados: preparé preguntas, registré respuestas y contribuí al mapeo de los procesos. A partir de eso, el equipo construyó desde cero la documentación y el modelado de datos, y participé en las distintas etapas. La implementación del nuevo sistema quedó a cargo de otra empresa.

El área de tecnología por dentro

Integré un grupo de trabajo, organizado en torno a un OKR, para discutir mejoras en el área de tecnología de Fluxo, analizando cuellos de botella y fortalezas y escuchando a otros miembros. Entre las medidas estuvieron la reorganización de la división entre backend y frontend hacia una actuación full stack, manteniendo el frente de diseño, y el apoyo a la formación técnica con cursos de Full Cycle. Esa participación amplió mi visión sobre cómo la organización de las personas y del aprendizaje influye en lo que un equipo logra construir.

Rutinas administrativo-financieras

En la Dirección Administrativo-Financiera, apoyé y ejecuté tareas de cuentas por pagar, incluidos reembolsos, y de conciliación bancaria, con reuniones diarias para seguir el avance y organizar los próximos pasos. Usé herramientas como Conta Azul, Asaas, Podio, Caju y Google Sheets. Fue mi contacto con las rutinas que sostienen el funcionamiento de una organización.

Reclutamiento y orientación

Participé en entrevistas y dinámicas del proceso de selección, haciendo preguntas, acompañando a los candidatos y registrando observaciones a partir de guiones y planillas de evaluación. Después, pasé a orientar a nuevos trainees, resolviendo dudas sobre las actividades y la empresa y evaluando sus entregas: una forma de compartir lo que había aprendido en mi propia formación.

Lo que me llevé de esta experiencia

En ocho meses, con frentes que muchas veces ocurrían al mismo tiempo, acerqué desarrollo de software, necesidades de usuarios, procesos internos y colaboración. El backend de la capacitación fue mi primera construcción en equipo; el proyecto de la industria mostró la importancia de investigar la rutina antes de definir un sistema; y las actividades internas ampliaron mi contacto con distintas responsabilidades dentro de una organización.

Tecnologías

• Node.js
• TypeScript
• NestJS
• PostgreSQL
• Prisma
• Git
• Scrum
• Kanban

Proyectos de esta experiencia

La visión técnica, con arquitectura y tecnologías, está en los detalles de cada proyecto.

• Modelado de sistema industrial
• Backend de sistema de gestión