Gracias por el A2A .
De hecho, he respondido esta pregunta muchas veces en otros sitios web, pero tal vez también falte aquí. Así que, aquí vamos :
La respuesta corta : “Construir un sistema de recomendación en una aplicación de Android / iOS en realidad no tiene sentido e inútil”. ¡Entonces no quieres hacer eso!
- ¿Cómo puedes crear un sistema de pago móvil?
- ¿De qué se tratan las sesiones del Acelerador de aplicaciones de Apple? ¿Qué debo esperar como desarrollador junior de iOS?
- ¿Qué debería aprender primero: Objective-C o Swift? ¿Por qué?
- ¿Qué es range in- (BOOL) textField: (UITextField *) theTextField shouldChangeCharactersInRange: (NSRange) range replaceString: (NSString *) string?
- ¿Qué inversión necesito para desarrollar una aplicación para iPhone?
Versión más larga de la respuesta:
Los algoritmos de Sistemas de recomendación son bastante caros de calcular / construir en cualquier recurso móvil y en cuanto al tiempo.
Por lo tanto, es mejor que lo hagan servidores dedicados que también pueden desempeñar un papel en el servicio de la información cuando sea necesario.
P: Entonces, ¿por qué digo eso?
Una de las cosas que debe saber sobre este tipo de sistemas es que en realidad implica desafíos de complejidad de tiempo y espacio al construirlos.
Esto significa que debe pasar tiempo trabajando y diseñando su sistema de recomendación y no solo el algoritmo.
Cuando generalmente construye una aplicación móvil, desea que esa aplicación reaccione instantáneamente. Esa es una de las bases de la Ingeniería de usabilidad.
P: Entonces, ¿qué significa eso?
Es el tipo de procesamiento que debe garantizar la respuesta dentro del tiempo especificado que en un sitio comercial interactivo es realmente muy bajo. Puede leer sobre ese tipo de especificaciones en esta respuesta en StackOverflow.
La mayoría de los sistemas informáticos existentes no ofrecen tanto lujo para predecir menos de 0.1 segundos y estoy citando
Extracto del Capítulo 5 en mi libro Ingeniería de usabilidad, de 1993:
- 0.1 segundos es aproximadamente el límite para que el usuario sienta que el sistema está reaccionando instantáneamente , lo que significa que no es necesaria una retroalimentación especial, excepto para mostrar el resultado.
Tener un sitio comercial interactivo en el que desee mostrar predicciones no significa que sus predicciones tengan que ser en tiempo real. Un usuario no quiere esperar días hasta que reciba la recomendación.
En pocas palabras, calculará recomendaciones / predicciones / perfiles en un sistema diferente utilizando su implementación interna, tal vez uno de su marco favorito, etc.
Muchos podrían no estar de acuerdo con la siguiente arquitectura, pero en aras de la viabilidad y la sencillez, una solución podría ser la siguiente:
P: Ahora que he calculado las recomendaciones para mis usuarios, ¿qué debo hacer?
R: Definamos una capa de servicio para nuestros sistemas lo suficientemente rápido como para consultar cuando se necesiten recomendaciones.
Puede ser lo suficientemente rápido como para responder sus llamadas, por ejemplo, Elasticsearch, Solr, HBase, Redis. Cualquier sabor que te convenga.
Por otro lado, bueno
P: No quiero que mi sistema sea estático, necesito volver a calcular mis predicciones cada T horas / días / etc.
R: Cualquier marco / trabajo puede programarse perfectamente aquí en un instante T. (un cron simple lo haría)
P: ¿ Pero cuándo vuelvo a entrenar mi sistema de recomendación?
R: Diría que en realidad depende de tantas cosas demasiado amplias para discutirlas aquí. Puede leer sobre el tema aquí si lo desea.
Ok, ahora definimos nuestra capa de lote .
P: ¿Y qué pasa con los datos que llegan en tiempo real, a través de Kafka, Rabbit, etc.?
R: Esto es en realidad cuando puede volverse más complicado, porque el método que usará para calcular distancias, aproximaciones, nuevas recomendaciones dependerá de qué tipo de sistemas de recomendación está construyendo y qué tecnologías está usando.
Cualquier marco de transmisión puede encajar muy bien para aplicar cálculos “simples” en micro lotes basados en “ventanas”. Esta puede ser nuestra capa de velocidad .
Para concluir, todo lo anterior define lo que se llama una arquitectura lambda. Es bastante interesante, deberías echarle un vistazo.
Lo que queda ahora es conectar esa API de Android que está creando a su capa de servicio y su sistema está listo.
Espero que esto responda a tu pregunta.
