quita archivos obsoletos

xepelin_challenge_answers/Caso 1 Diseño de Sistemas 839256bb6649407d9dc58bf1f8cde3ee.md

@@ -1,165 +0,0 @@
-# Caso 1: Diseño de Sistemas
-
-## El problema de negocio y del problema de ingeniería
-
-## El problema de negocio:
-
-Cada vez que recibe una operación de financiamiento (compuesta por una o más facturas que el cliente busca financiar), Xepelin debe ser capaz de producir una métrica de riesgo de crédito para cada una de las facturas que componen la operación de financiamiento. 
-
-Al momento de recibir una solicitud de operación de financiamiento, recibiremos información sobre payerid, businessid, y monto de la factura, y deberemos obtener todos los datos sobre estos id, incluyendo la relación entre ambos, para realizar nuestra predicción. El modelo emitirá una recomendación sobre si es conveniente o no financiar la factura. 
-
- 
-
-## **El problema de ingeniería:**
-
-Desde un punto de vista de Machine Learning debemos desarrollar un producto de datos que permita : 
-
-- Producir respuestas near real time para que sean usadas de input para tomar decisiones.
-- Monitoreo de la calidad de predicciones de nuestro modelo y de la estabilidad de nuestro sistema.
-- Un workflow CI / CD en el que nuestros desarrolladores puedan seguir desarrollando y poniendo en producción versiones mejoradas de nuestro modelo y de nuestro producto de datos.
-
-(Asumo que hay un dato con el que no contábamos previamente al momento de la solicitud que es el monto de la factura, lo que nos impide calcular en batch y nos obliga a calcular “al vuelo”.)
-
-![Screenshot 2024-01-12 at 1.37.19 p.m..png](Caso%201%20Disen%CC%83o%20de%20Sistemas%20839256bb6649407d9dc58bf1f8cde3ee/Screenshot_2024-01-12_at_1.37.19_p.m..png)
-
-Se propone desarrollar el sistema en los servicios de AWS integrados en una lógica de Infrastructure as a Service (IaaS) a travé de Gitlab Actions y orquestado a través de Airflow. 
-
-Los principales servicios a utilizar serán: 
-
-- **Step functions + Glue** para desarrollar el Pipeline de Procesamiento diario de datos en Batch y el Pipeline de Reentrenamiento del Modelo
-- Lambda para
-- **PostgreSQL** para guardar las predicciones de nuestro modelo
-- **MongoDB** para obtener los datos sobre business y payer al momento de realizar las predicciones.
-- **S3** para guardar datos sobre facturas, el pkl del modelo de ML
-- **EMR** para guardar las versiones de los modelos
-- **Gitlab + Cloudformation:** Para administrar el CI CD y deployear los servicios en ambientes de dev, stage y prod, de modo que los desarrolladores puedan seguir trabajando en nuevos desarrollos y que haya una forma de integración fluida de nuevos procesos.
-- **Airflow:** para orquestar y monitorear de manera general nuestro sistema, en particular asegurarse que no fallen los procesos que tienen que correr en batch.
-
-A continuación, se explican en detalle cuatro ejes fundamentales de este sistema: 
-
-1. La Lambda que recibe solicitudes de operación de financiamiento y devuelve predicciones
-2. El procesamiento de diario de datos que actualiza en batch:
-    1.  datos business+payer 
-    2.  métricas de monitoreo 
-3. El modelo y el reentrenamiento del modelo 
-4. CI/CD y versionado 
-5. Monitoreo general del sistema 
-
-## 1. Lambda: **Solicitud de operación de financiamiento**
-
-Al momento de recibir una operación de financiamiento a través de un llamado POST a nuestra API:
-
-- El front end (del sitio web de xepelin) raeliza una llamada a la Lambda.
-- se recibe una lista de facturas. (Asumo que para cada factura, se recibe datos del businessid y del pagador, así como monto de la factura, con el cual no se contaba previamente )
-- Se hace la búsqueda correspondiente con el id business+pagador en la base MongoDb (optimizada para buscar por índices), lo que nos provee de todos los datos relevantes que han sido procesados en batch previamente (ver el punto siguiente).
-- se realiza la predicción para cada factura
-- se devuelve los datos predichos al front
-- Se escriben las predicciones realizadas por nuestro modelo en una base de datos, para monitoreo futuro.
-
-Comentario: Lambda tiene un límite de concurrencia de 1000 peticiones simultáneas por region (de AWS). En caso de que se quisiera aumentar, se podría distribuir lambdas en distintas regiones. Esta cuestión es el punto más sensible vinculado a la escalabilidad de nuestro sistema.
-
-## 2. **Procesamiento diario de datos**
-
-Procesos diario que corre en batch cada medianoche con pipelines desarrollados en StepFunctions y Glue.
-
-Se necesita procesar, cada noche, dos procesamientos: 
-
-- **Datos para predicción:** Datos actualizados de cada businessid en su relación con cada uno de los payer id.
-- **Datos para monitoreo y reentrenamiento:** Datos de cada factura existente, con todas las variables del modelo y la cantidad de días que se tardó en pagar, así como con la predicción previa que había realizado el modelo. Esto permite generar métricas de monitoreo y tener listas los datos para el momento de reentrenamiento.
-
-### 2.a. Procesamiento diario business+payer
-
-Un Pipeline diario, que puede correr a medianoche, precalcula y actualiza todas las variables que se necesitarán al momento de realizar una predicción a excepción del monto de la factura. Este pipeline puede escribirse en python o Spark dependiendo del volumen de datos. 
-
-Los datos quedarán guardados en S3 y en MongoDb. 
-
-- La tabla MongoDb permite una búsqueda optimizada por índice. El índice de la tabla será *un índice compuesto businessid + payer id*. De este modo, nuestra base tendría precalculada una línea por cada relación entre business id con cada payer id (para el que exista una relación previa), y dado que estaría optimizada para la búsqueda, solo debemos buscar una línea por cada factura, teniendo todos los datos disponibles para que el modelo genere la predicción (a excepción del monto de cada factura, que recibiremos en la solicitud de financiamiento).
-- En S3 se guardarán los datos en una estructura de carpetas de año, mes, día, donde el día será el día de recálculo (ya que algunos datos varían diariamente). Esto no será utilizado para el modelo pero permite tener un registro por cuestiones de gobernanza de datos.
-
-Datos precalculados al inicio de cada día: 
-
-      los datos vinculados al businessId;
-
-- **businessId**: Identificador del emisor (business).
-- **issuerInvoicesAmount**: Monto total de facturas emitidas por businessId.
-- **clients12Months**: Cantidad de clientes del emisor businessId (últimos 12 meses).
-
- los datos vinculados a la relación entre businessId y payerId, 
-
-- **relationDays**: Días desde el inicio de la relación business-payer.
-- **relationRecurrence**: Días recurrencia promedio de la interacción (últimos 12 meses).
-- **issuerCancelledInvoices**: Ratio de facturas canceladas del businessId.
-
-y los datos vinculados a payerId
-
-- **payerId**: Identificador del pagador de la factura.
-- **activityDaysPayer**: Días transcurridos desde el inicio de actividades del pagador
-    
-    (payerId).
-    
-
-Datos recibidos en la llamada a la API: 
-
-los datos específicos de una factura: 
-
-- **receiptAmount**: Monto de la factura de la operación.
-
-Comentarios: 
-
-- Este sistema no sería correcto si hay casos en que un mismo cliente envía una cantidad muy alta de solicitudes de financiamiento en un mismo día, y queremos que cada solicitud tome en cuenta las respuestas a las solicitudes anteriores.
-- A su vez, para evitar el crecimiento indefinido de esta tabla se puede
-- Es necesario gestionar los recibimientos de nuevas relaciones business+payer que no existieran previamente, así como el ingreso de nuevos clientes. Probablemente estos casos deben ser derivados a un agente especializado de Xepelin, ya que el modelo no contaría con información suficiente para hacer predicciones confiables en estos casos.
-
-Descripción del pipeline de procesamiento de datos:
-
-![Screenshot 2024-01-12 at 12.29.46 p.m..png](Caso%201%20Disen%CC%83o%20de%20Sistemas%20839256bb6649407d9dc58bf1f8cde3ee/Screenshot_2024-01-12_at_12.29.46_p.m..png)
-
-**inbound:** ingesta datos del data lake de BI de Xepelin (relacionados a las facturas financiadas así como a los businessid y payerid), 
-
-**Validations:** realiza validaciones a los datos (medias de columnas, nulos esperados, valores atípicos, etc.) 
-
-**Prod**: procesa los datos de modo que estén listos para ser tomados por nuestro modelo para realizar predicciones y los guarda en una base de datos MongoDb y en S3. 
-
-**Notification:** A su vez, envía un reporte a slack en caso de encontrar algo extraño en los datos. 
-
-### 2.b. **Monitoreo del modelo. (esto debería ir junto a la parte de extracción) …**
-
-El Pipeline de monitoreo de modelo tiene una estructura similar al anterior (inbound, validations, prod, notifications) y corre cada día a medianoche:
-
-- fuente de datos:
-    - BI sobre pagos reales de facturas (qué facturas se pagaron y cuales no y en cuanto tiempo)
-    - predicciones que originalmente hizo el modelo y que se guardan al final del llamado de cada Lambda.
-- procesamiento de datos:
-    - Transformación de variables de tiempo sin pagar en niveles de riesgo crediticio (alto, medio, bajo), etc.
-    - Almacenamiento de datos para reentrenamiento de modelo
-- métricas:
-    - métricas para modelos de clasificación, como precisión, recall, y matriz de confusión, con particular énfasis en los casos de detección de casos impagos
-    - La métrica debe hacerse en una (o varias) ventana(s) de tiempo de datos recientes, por ejemplo, una semana, un mes, tres meses, para detectar de manera temprana una caída de rendimiento del modelo.
-- Notificaciones en slack con reporte de métricas: solo una vez por semana o en caso de detectar métricas atípicas.
-
-## 3. El modelo y el **Reentrenamiento del modelo**
-
-Utilizaremos un modelo de ML tipo LightGBM Classifier, que permita resolver un problema de clasificación. 
-
-- El modelo clasificará cualquier pedido de factura con un nivel de riesgo alto, medio o bajo, dependiendo la cantidad de días de mora estimados y el valor de la factura.
-- Métricas: ver monitoreo del mondelo (arriba)
-
-El reentrenamiento del modelo: 
-
-- Se dará de forma semanal (por ejemplo, los domingo a medianoche)
-- Tendrá una y de manera automática en una lógica *challenger-defender*. Esto significa que se entrenará un nuevo modelo y se  comparará las métricas del nuevo modelo con las métricas del modelo actualmente en producción con datos para una misma ventana de tiempo. Si el nuevo modelo es mejor, reemplazará automáticamente al anterior.
-- El reentrenamiento semanal con datos de una ventana de tiempo reciente permite ir captando cambios lentos en el mercado o en comportamiento de los agentes, que pudieran estar afectando las predicciones.
-
-### 4. **CI / CD y versionado de modelos**
-
-Nuestro producto de datos requerirá un mejoramiento constante. Más allá de los reentrenamientos semanales del modelo, un equipo de desarrolladores buscará modelos superadores que serán el corazón de Xepelin. Para ello necesitamos un sistema de CI CD con las siguientes caractéristicas: 
-
-- Una forma de deployear nuestros servicios con una lógica Infrastracture as a service (Iaas) a través de la integración de Gitlab y CloudFormation.
-- tres ambientes de desarrollo dev, stage y prod, y un sistema fluido para ir pasando de un sistema a otro
-- Un sistema de versionado de modelos (se considera una nueva versión cuando un desarrollador pone en producción y no el reentrenamiento automático) a través de Model Registry, y en el que se guarde información sobre código (Git), ambiente (versiones de imágenes de Docker), especificaciones técnicas, métricas, etc.
-
-### 5. Monitoreo general del sistema
-
-- El sistema general será orquestado a través de Airflow, lo que permitirá:
-    - una UI centralizada de monitoreo del sistema
-    - resiliencia general del sistema, permitiendo retrys específicos en caso de fallo

xepelin_challenge_answers/Caso 2 Prueba Técnica f149617afd8941158f81c47c0e59c9ce.md

@@ -1,36 +0,0 @@
-# Caso 2: Prueba Técnica
-
-## 
-
-## La API
-
-Se deployeó una api en hugging face. Este es el Endpoint al que se realliza un llamado POST:
-
-[`https://sanbatte-finance-api.hf.space/predict/`](https://sanbatte-finance-api.hf.space/predict/)
-
-Ejemplo de payload: 
-
-```
-{
-  "invoiceId": [18314, 16632, 15639 ],
-  "country": "CL"
-}
-```
-
-La API recibe la llamada, calcula la predicción del modelo en el momento y devuelve la predicción para cada invoiceId
-
-La API solo acepta los códigos de país CL y MX. En caso de recibir otro código, devuelve errror. 
-
-La API solo acepta que los invoice sean números enteros que estén en el csv y que vengan en una lista.  
-
-El código de la API se puede ver acá: 
-
-[sanbatte/finance_api at main](https://huggingface.co/spaces/sanbatte/finance_api/tree/main)
-
-## El Modelo
-
-Se entreno un modelo LightGBM, un modelo de gradient boosting optimizado para su rápido rendimiento y velocidad de respuesta al momento de la producción (ideal para ambientes de producción). 
-
-El entrenamiento del modelo y justificación de las decisiones tomadas se puede ver acá: 
-
-AGREGAR NOTEBOOK