Esta es una publicación de invitado de Oliver Frost, científico de datos de ImmoScout24, en colaboración con Lukas Müller, arquitecto de soluciones de AWS.

En 2010, ImmoScout24 publicó un índice de precios para bienes raíces residenciales en Alemania: el IMX. Se basó en los listados de ImmoScout24. Además del precio, los listados suelen contener mucha información específica, como el año de construcción, el tamaño de la parcela o el número de habitaciones. Esta información nos permitió construir el denominado índice de precios hedónicos, que considera las características particulares de un inmueble.

Cuando lanzamos el IMX, nuestro objetivo era establecerlo como el índice estándar de precios inmobiliarios en Alemania. Sin embargo, luchó por capturar el aumento de precios en el mercado inmobiliario alemán desde la crisis financiera de 2008. Además, como un índice bursátil, era una cifra abstracta que no se puede interpretar directamente. Por lo tanto, el IMX fue difícil de comprender para los no expertos.

En ImmoScout24, nuestra misión es hacer que las decisiones complejas sean fáciles, y nos dimos cuenta de que necesitábamos un nuevo concepto para cumplirlo. En lugar de otro índice, decidimos crear un informe de mercado que todos puedan entender fácilmente: el WohnBarometer. Se basa en los datos de nuestros listados y tiene en cuenta las propiedades de los objetos. La diferencia clave con el IMX es que el WohnBarometer muestra los precios de alquiler y venta en euros por metro cuadrado para tipos de bienes inmuebles residenciales específicos a lo largo del tiempo. Por lo tanto, las cifras se pueden interpretar directamente y permiten a nuestros clientes responder preguntas como "¿Pago demasiado alquiler?" o “¿El apartamento que estoy a punto de comprar tiene un precio razonable?” o "¿Qué ciudad en mi región es la más prometedora para invertir?" Actualmente, el WohnBarometer se informa para Alemania en su conjunto, las siete ciudades más grandes y los mercados locales alternos.

El siguiente gráfico muestra un ejemplo del WohnBarometer, con precios de venta para Berlín y el desarrollo por trimestre.

Esta publicación analiza cómo ImmoScout24 usó Amazon SageMaker crear el modelo del WohnBarometer para que sea relevante para nuestros clientes. Analiza el modelo de datos subyacente, el ajuste de hiperparámetros y la configuración técnica. Esta publicación también muestra cómo SageMaker ayudó a un científico de datos a completar el WohnBarometer en 2 meses. Todo un equipo tardó 2 años en desarrollar la primera versión del IMX. Tal inversión no era una opción para el WohnBarometer.

Acerca de ImmoScout24

ImmoScout24 es la plataforma en línea líder para bienes raíces residenciales y comerciales en Alemania. Durante más de 20 años, ImmoScout24 ha revolucionado el mercado inmobiliario y apoya a más de 20 millones de usuarios cada mes en su mercado en línea o en su aplicación para encontrar nuevos hogares o espacios comerciales. Es por eso que el 99% de nuestro grupo de clientes objetivo conocen ImmoScout24. Con sus soluciones digitales, el mercado en línea coordina y reúne con éxito a propietarios, agentes inmobiliarios, inquilinos y compradores. ImmoScout24 está trabajando con el objetivo de digitalizar el proceso de transacciones inmobiliarias y, por lo tanto, facilitar las decisiones complejas. Desde 2012, ImmoScout24 también ha estado activo en el mercado inmobiliario austriaco, alcanzando alrededor de 3 millones de usuarios mensuales.

De las instalaciones a AWS Data Pipeline a SageMaker

En esta sección, analizamos la configuración anterior y sus desafíos, y por qué decidimos usar SageMaker para nuestro nuevo modelo.

La configuración anterior

Cuando se publicó la primera versión de IMX en 2010, la nube seguía siendo un misterio para la mayoría de las empresas, incluida ImmoScout24. El campo del aprendizaje automático (ML) estaba en su infancia y solo un puñado de expertos sabía cómo codificar un modelo (a modo de ilustración, el primer lanzamiento público de Scikit-Learn fue en febrero de 2010). No sorprende que el desarrollo del IMX tomó más de 2 años y costó una suma de siete cifras.

En 2015, ImmoScout24 comenzó su migración a AWS y reconstruyó IMX en la infraestructura de AWS. Con los datos de nuestra Servicio de almacenamiento simple de Amazon (Amazon S3), tanto el preprocesamiento de datos como el entrenamiento del modelo ahora se realizaron en EMR de Amazon grupos orquestados por Tubería de datos de AWS. Mientras que la primera era una aplicación PySpark ETL, la segunda eran varias secuencias de comandos de Python que usaban paquetes de ML clásicos (como Scikit-Learn).

Problemas con esta configuración

Aunque esta configuración demostró ser bastante estable, no fue fácil solucionar los problemas de la infraestructura o mejorar el modelo. Un problema clave con el modelo era su complejidad, porque algunos componentes habían comenzado una vida por sí mismos: al final, el código de la detección de valores atípicos era casi el doble de largo que el código del modelo IMX principal.

El modelo central, de hecho, no era un modelo, sino cientos: un modelo por tipo de propiedad residencial y región, con una definición que variaba desde un solo vecindario en una gran ciudad hasta varias aldeas en áreas rurales. Teníamos, por ejemplo, un modelo para apartamentos en venta en el centro de Berlín y un modelo para casas en venta en un suburbio de Munich. Debido a que configurar el entrenamiento de todos estos modelos tomó mucho tiempo, omitimos el ajuste de hiperparámetros, lo que probablemente provocó que los modelos tuvieran un rendimiento inferior.

Por qué nos decidimos por SageMaker

Dados estos problemas y nuestra ambición de tener un informe de mercado con beneficios prácticos, tuvimos que decidir entre reescribir gran parte del código existente o comenzar desde cero. Como se puede inferir de esta publicación, optamos por lo último. Pero, ¿por qué SageMaker?

La mayor parte del tiempo que pasamos en el IMX se dedicó a solucionar problemas de infraestructura, no a mejorar el modelo. Para el nuevo informe de mercado, queríamos darle la vuelta a esto, centrándonos en el rendimiento estadístico del modelo. También queríamos tener la flexibilidad para reemplazar rápidamente los componentes individuales del modelo, como la optimización de los hiperparámetros. ¿Qué pasa si aparece un nuevo algoritmo de impulso superior (piense en cómo XGBoost llegó al escenario en 2014)? ¡Por supuesto, queremos adoptarlo como uno de los primeros!

En SageMaker, los componentes principales del flujo de trabajo clásico de ML (preprocesamiento, capacitación, ajuste de hiperparámetros e inferencia) están claramente separados en el nivel de la API y también en el Consola de administración de AWS. Modificarlos individualmente no es difícil.

El nuevo modelo

En esta sección, analizamos los componentes del nuevo modelo, incluidos los datos de entrada, el algoritmo, el ajuste de hiperparámetros y la configuración técnica.

Datos de entrada

El WohnBarometer se basa en una ventana deslizante de 5 años de listados de ImmoScout24 de bienes raíces residenciales ubicados en Alemania. Después de eliminar los valores atípicos y los listados fraudulentos, nos quedan aproximadamente 4 millones de listados que se dividen en tren (60 %), validación (20 %) y datos de prueba (20 %). La relación entre listados y objetos no es necesariamente 1:1; en el transcurso de 5 años, es probable que el mismo objeto se inserte varias veces (por varias personas).

Usamos 13 atributos de listado, como la ubicación de la propiedad (coordenadas WGS84), el tipo de propiedad (casa o apartamento, venta o alquiler), su antigüedad (años), su tamaño (metro cuadrado) o su condición (por ejemplo , nuevos o reacondicionados). Dado que cada listado típicamente
y viene con decenas de atributos, surge la pregunta: ¿cuál incluir en el modelo? Por un lado, utilizamos el conocimiento del dominio; por ejemplo, es bien sabido que la ubicación es un factor clave, y en casi todos los mercados las propiedades nuevas son más caras que las existentes. Por otro lado, nos basamos en nuestras experiencias con el IMX y modelos similares. Allí aprendimos que incluir docenas de atributos no mejora significativamente el modelo.

Dependiendo del tipo de inmueble del listado, la variable objetivo de nuestro modelo es la renta por metro cuadrado o el precio de venta por metro cuadrado (más adelante explicamos por qué esta elección no fue la ideal). A diferencia del IMX, el WohnBarometer es, por lo tanto, un número que nuestros clientes pueden interpretar y actuar directamente.

Descripcion del modelo

Al usar SageMaker, puede elegir entre diferentes estrategias para implementar su algoritmo:

• Utilice uno de los algoritmos integrados de SageMaker. Hay casi 20 y cubren todos los principales tipos de problemas de ML.
• Personalice una imagen de Docker prefabricada basada en un marco de ML estándar (como Scikit-Learn o PyTorch).
• Cree su propio algoritmo e impleméntelo como una imagen de Docker.

Para WohnBarometer, queríamos una solución que fuera fácil de mantener y que nos permitiera centrarnos en mejorar el modelo en sí, no la infraestructura subyacente. Por lo tanto, nos decidimos por la primera opción: usar un algoritmo completamente administrado con la documentación adecuada y soporte rápido si es necesario. A continuación, necesitábamos elegir el algoritmo en sí. Una vez más, la decisión no fue difícil: optamos por el algoritmo XGBoost porque es uno de los algoritmos de ML más reconocidos para problemas de tipo regresión y ya lo hemos utilizado con éxito en varios proyectos.

Ajuste de hiperparámetros

La mayoría de los algoritmos de ML vienen con una miríada de parámetros para modificar. Los algoritmos de impulso, por ejemplo, tienen muchos parámetros que especifican cómo se construyen exactamente los árboles: ¿Los árboles tienen un máximo de 20 o 30 hojas? ¿Cada árbol se basa en todas las filas y columnas o solo en muestras? ¿Cuánto podar los árboles? Encontrar los valores óptimos de esos parámetros (medidos por una métrica de evaluación de su elección), el llamado ajuste de hiperparámetros, es fundamental para construir un modelo de ML poderoso.

Una pregunta clave en el ajuste de hiperparámetros es qué parámetros ajustar y cómo establecer los rangos de búsqueda. Podría preguntar, ¿por qué no comprobar todas las combinaciones posibles? Aunque en teoría esto suena como una buena idea, resultaría en un enorme espacio de hiperparámetros con demasiados puntos para evaluarlos todos a un precio razonable. Es por eso que los profesionales de ML generalmente seleccionan una pequeña cantidad de hiperparámetros que se sabe que tienen un fuerte impacto en el rendimiento del algoritmo elegido.

Después de definir el espacio de hiperparámetros, la siguiente tarea es encontrar la mejor combinación de valores en él. Las siguientes técnicas son comúnmente empleadas:

• búsqueda de cuadrícula – Divida el espacio en una cuadrícula discreta y luego evalúe todos los puntos en la cuadrícula con validación cruzada.
• Búsqueda aleatoria – Dibujar combinaciones al azar del espacio. Con este enfoque, lo más probable es que se pierda la mejor combinación, pero sirve como un buen punto de referencia.
• Optimización bayesiana – Construir un modelo probabilístico de la función objetivo y utilizar este modelo para generar nuevas combinaciones. El modelo se actualiza después de cada combinación, lo que conduce rápidamente a buenos resultados.

En los últimos años, gracias a la potencia informática barata, la optimización bayesiana se ha convertido en el estándar de oro en el ajuste de hiperparámetros y es la configuración predeterminada en SageMaker.

Configuración técnica

Al igual que con muchos otros servicios de AWS, puede crear trabajos de SageMaker en la consola, con el Interfaz de línea de comandos de AWS (AWS CLI) o mediante código. Elegimos la tercera opción, SageMaker Python SDK para ser precisos, porque permite una configuración altamente automatizada: WohnBarometer vive en un proyecto de software de Python que es ejecutable desde la línea de comandos. Por ejemplo, todos los pasos de la canalización de ML, como el preprocesamiento o el entrenamiento del modelo, se pueden activar mediante comandos Bash. Esos comandos de Bash, a su vez, están orquestados con una canalización de Jenkins impulsada por AWS Fargate.

Veamos los pasos y la infraestructura subyacente:

• preprocesamiento – El preprocesamiento se realiza con la biblioteca Scikit-Learn integrada en SageMaker. Debido a que implica unir marcos de datos con millones de filas, necesitamos una máquina ml.m5.24xlarge aquí, la más grande que puede obtener en la familia ml.m. Alternativamente, podríamos haber usado varias máquinas más pequeñas con un marco distribuido como Dask, pero queríamos que fuera lo más simple posible.
• Formación – Usamos el algoritmo predeterminado SageMaker XGBoost. El entrenamiento se realiza con dos máquinas ml.m5.12xlarge. Vale la pena mencionar que nuestro train.py que contiene el código de entrenamiento del modelo y el ajuste de hiperparámetros tiene menos de 100 filas.
• Ajuste de hiperparámetros – Siguiendo el principio de menos es más, solo ajustamos 11 hiperparámetros (por ejemplo, el número de rondas de refuerzo y la tasa de aprendizaje), lo que nos da tiempo para elegir cuidadosamente sus rangos e inspeccionar cómo interactúan entre sí. Con solo unos pocos hiperparámetros, cada trabajo de entrenamiento se ejecuta relativamente rápido; en nuestro caso, los trabajos tardan entre 10 y 20 minutos. Con un número máximo de 30 trabajos de formación y 2 trabajos simultáneos, el tiempo total de formación es de unas 3 horas.
• Inferencia – SageMaker ofrece múltiples opciones para servir su modelo. Usamos trabajos de transformación por lotes porque solo necesitamos los números de WohnBarometer una vez por trimestre. No usamos un punto final porque estaría inactivo la mayor parte del tiempo. Cada trabajo por lotes (aproximadamente 6.8 millones de filas) es atendido por una sola máquina ml.m5.4xlarge en menos de 10 minutos.

Podemos depurar fácilmente estos pasos en la consola de SageMaker. Si, por ejemplo, un trabajo de capacitación está demorando más de lo esperado, navegamos a la Formación página, ubique el trabajo de capacitación en cuestión y revise Reloj en la nube de Amazon métricas de las máquinas subyacentes.

El siguiente diagrama de arquitectura muestra la infraestructura del WohnBarometer:

Retos y aprendizajes

Al principio todo transcurrió sin problemas: en pocos días configuramos el proyecto de software y entrenamos una versión en miniatura de nuestro modelo en SageMaker. Teníamos grandes esperanzas puestas en la primera ejecución del conjunto de datos completo y la puesta a punto de los hiperparámetros. Desafortunadamente, los resultados no fueron satisfactorios. Tuvimos los siguientes problemas clave:

• Las predicciones del modelo eran demasiado bajas, tanto para el alquiler como para la venta de objetos. Para Berlín, por ejemplo, los precios de venta previstos para nuestros objetos de referencia estaban aproximadamente un 50 % por debajo de los precios de mercado.
• Según el modelo, no hubo una diferencia de precio significativa entre los edificios nuevos y los existentes. La verdad es que los edificios nuevos casi siempre son significativamente más caros que los edificios existentes.
• El efecto de la ubicación en el precio no se capturó correctamente. Sabemos, por ejemplo, que los apartamentos en venta en Frankfurt am Main son, en promedio, más caros que en Berlín (aunque Berlín se está poniendo al día); nuestro modelo, sin embargo, lo predijo al revés.

¿Cuál era el problema y cómo lo solucionamos?

Muestreo de las caracteristicas

A primera vista, parece que los problemas no están relacionados
, pero de hecho lo son. De forma predeterminada, XGBoost crea cada árbol con una muestra aleatoria de las características. Digamos que un modelo tiene 10 características F₁, F₂,… F₁₀, entonces el algoritmo podría usar F₁, F₄, y F₇ para un árbol, y F₃, F₄, y F₈ Por otro. Si bien, en general, este comportamiento evita de manera efectiva el sobreajuste, puede ser problemático si la cantidad de características es pequeña y algunas de ellas tienen un gran efecto en la variable de destino. En este caso, muchos árboles perderán las características cruciales.

El muestreo de XGBoost de nuestras 13 características dio lugar a muchos árboles que no incluían ninguna de las características cruciales (tipo de inmueble, ubicación y edificios nuevos o existentes) y, como consecuencia, causaron estos problemas. Por suerte, hay un parámetro para controlar el muestreo: colsample_bytree (de hecho, hay dos parámetros más para controlar el muestreo, pero no los tocamos). Cuando revisamos nuestro código, vimos que colsample_bytree se estableció en 0.5, un valor que conservamos de proyectos anteriores. Tan pronto como lo establecimos en el valor predeterminado de 1, los problemas anteriores desaparecieron.

Un modelo frente a varios modelos

A diferencia del IMX, el modelo WohnBarometer realmente es solo un modelo. Aunque esto minimiza el esfuerzo de mantenimiento, no es ideal desde un punto de vista estadístico. Debido a que nuestros datos de entrenamiento contienen tanto objetos de venta como de alquiler, la dispersión en la variable objetivo es enorme: varía desde menos de 5 euros para algunos apartamentos de alquiler hasta muy por encima de 10,000 5 euros para casas en venta en ubicaciones de primera clase. El gran reto de la modelo es comprender que un error de XNUMX euros es fantástico para los objetos en venta, pero desastroso para los objetos en alquiler.

En retrospectiva, sabiendo lo fácil que es mantener varios modelos en SageMaker, habríamos creado al menos dos modelos: uno para alquilar y otro para vender. Esto facilitaría la captura de las peculiaridades de ambos mercados. Por ejemplo, el precio de los apartamentos en venta sin alquilar suele ser entre un 20% y un 30% más alto que el de los apartamentos en venta alquilados. Por lo tanto, codificar esta información como una variable ficticia en el modelo de venta tiene mucho sentido; para el modelo de alquiler, por otro lado, podría omitirlo.

Conclusión

¿El WohnBarometer cumplió con el objetivo de ser relevante para nuestros clientes? Tomando la cobertura de los medios como una indicación, la respuesta es un claro sí: hasta noviembre de 2021, se han publicado más de 700 artículos de periódicos y reportajes de radio o televisión sobre el WohnBarometer. La lista incluye periódicos nacionales como Frankfurter Allgemeine Zeitung, Tagesspiegel y Handelsblatt, y periódicos locales que a menudo solicitan cifras del WohnBarometer para su región. Debido a que calculamos las cifras para todas las regiones de Alemania de todos modos, nos complace aceptar tales solicitudes. Con el antiguo IMX, este nivel de granularidad no era posible.

El WohnBarometer supera al IMX en lo que respecta al rendimiento estático, en particular en lo que respecta a los costos: el IMX fue generado por un clúster EMR con 10 nodos de tareas que se ejecutan casi medio día. En contraste, todos los pasos del WohnBarometer toman menos de 5 horas usando máquinas medianas. Esto se traduce en un ahorro de costes de casi el 75%.

Gracias a SageMaker, pudimos poner en producción un modelo de ML complejo con un científico de datos en menos de 2 meses. Esto es notable. 10 años antes, cuando ImmoScout24 construyó el IMX, alcanzar el mismo hito tomó más de 2 años e involucró a todo un equipo.

¿Cómo podemos ser tan eficientes? SageMaker nos permitió centrarnos en el modelo en lugar de la infraestructura, y SageMaker promueve una arquitectura de microservicios que es fácil de mantener. Si nos quedamos atascados con algo, podríamos llamar al soporte de AWS. En el pasado, cuando fallaba una de nuestras canalizaciones de datos IMX, a veces dedicábamos días a depurarla. Desde que comenzamos a publicar las cifras del WohnBarometer en abril de 2021, la infraestructura de SageMaker no ha fallado ni una sola vez.

Para obtener más información sobre el WohnBarometer, consulte WohnBarómetro y WohnBarómetro: Angebotsmieten stiegen 2021 bundesweit wieder stärker an. Para obtener más información sobre el uso de la biblioteca SageMaker Scikit-Learn para el preprocesamiento, consulte Preprocesar los datos de entrada antes de realizar predicciones mediante canalizaciones de inferencia de Amazon SageMaker y Scikit-learn. Envíenos sus comentarios, ya sea en el Foro de AWS para Amazon SageMakero a través de sus contactos de soporte de AWS.

El contenido y las opiniones de esta publicación pertenecen al autor externo y AWS no es responsable del contenido o la precisión de esta publicación.

Acerca de los autores

Oliver escarcha se unió a ImmoScout24 en 2017 como analista de negocios. Dos años más tarde, se convirtió en científico de datos en un equipo cuyo trabajo es convertir los datos de ImmoScout24 en verdaderos productos de datos. Antes de construir el modelo WohnBarometer, ejecutó proyectos más pequeños de SageMaker. Oliver posee varios certificados de AWS, incluida la especialidad de aprendizaje automático.

lukas muller es arquitecto de soluciones en AWS. Trabaja con clientes en las industrias de deportes, medios y entretenimiento. Siempre está buscando formas de combinar la habilitación técnica con la habilitación cultural y organizacional para ayudar a los clientes a lograr valor comercial con las tecnologías de la nube.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://aws.amazon.com/blogs/machine-learning/predict-residential-real-estate-prices-at-immoscout24-with-amazon-sagemaker/