Cómo añadir un sistema de recomendación a tu producto (lo aprendido en dos proyectos)

Cuando una plataforma pasa de unas decenas de fichas a varios cientos, sean profesionales, eventos, contenidos o productos, es habitual que la gente acabe viendo siempre las mismas y que mucho de lo que hay no lo encuentre nadie. En ese momento suele aparecer la idea de usar IA para recomendar, y con ella las preguntas de siempre sobre cuánto cuesta, cuántos datos hacen falta y si merece la pena.

En Softspring hemos construido 2 sistemas de recomendación a medida con necesidades muy distintas. Uno sugiere a la coordinadora de una plataforma de psicología qué psicólogas encajan con cada paciente. El otro recomienda destinos, eventos y actividades a los miembros de una comunidad de nómadas digitales a partir de lo que cuentan que buscan y de por dónde han pasado. El problema de fondo es parecido, pero los datos disponibles eran muy diferentes y eso condicionó casi todas las decisiones. 

Qué decisión quieres ayudar a tomar. Asignar a la profesional que va a acompañar a alguien durante meses es una decisión importante, que se toma una vez y con mucho en juego. Elegir el próximo destino o a qué actividad apuntarse es más ligero y se repite a menudo. Cada caso pide un sistema distinto y también un grado distinto de intervención humana.

Cómo vas a saber si la recomendación ha acertado. Sin esa respuesta es muy difícil mejorar el sistema, y el clic rara vez sirve como medida. En el primer caso, acertar puede ser que el paciente continúe después de la primera sesión. En el segundo, que la persona acabe reservando o apuntándose a algo de lo que se le ha propuesto. 

Cuánto catálogo y cuánta actividad tienes. Con 40 profesionales y un buscador con buenos filtros (especialidad, idioma, horario, precio) puede que el problema ya esté resuelto. Un recomendador empieza a compensar cuando el catálogo es más grande de lo que nadie puede revisar a mano, o cuando la elección depende de matices que no caben en un desplegable, como explicar con tus propias palabras por qué buscas ayuda o qué tipo de viaje te apetece.

Si al repasar esto ves que basta con mejorar los filtros y la búsqueda, mejor saberlo al principio. Es más barato, da menos mantenimiento y nadie tiene que justificar por qué el sistema ha propuesto una cosa y no otra.

• Filtrado por contenido: recomienda elementos parecidos a lo que la persona dice querer o ya ha usado, comparando sus características.
• Filtrado colaborativo: recomienda lo que les gustó a otras personas que se comportan de forma parecida.

El primero funciona desde el primer día si el catálogo está bien descrito. El segundo necesita bastante historial. Muchos sistemas en producción combinan los dos y van cambiando el peso de cada uno a medida que acumulan datos. Los 2 proyectos que contamos aquí se apoyan sobre todo en el primero, porque ninguno tenía historial suficiente para el segundo.

 Los modelos de lenguaje han cambiado bastante el filtrado por contenido. Con embeddings (representar un texto como una lista de números para poder comparar significados en lugar de palabras exactas) se puede relacionar «quiero un sitio tranquilo con buena conexión y cerca del mar» con un destino cuya ficha habla de calas, coworkings y temporada baja, aunque no compartan ninguna palabra. Es la misma técnica que usamos en los sistemas RAG con documentación de empresa.

La Psicóloga en Casa es una plataforma de psicología online. Cuando alguien se registra, cuenta su motivo de consulta con sus palabras, y la plataforma tiene que asignarle una psicóloga entre las disponibles.

Qué datos hay. Prácticamente ninguno de comportamiento. Cada paciente llega una vez, sin historial, y la decisión le afecta mucho. El filtrado colaborativo no tenía sentido aquí: no hay suficientes «pacientes parecidos a ti que eligieron a esta psicóloga», y aunque los hubiera, tampoco es un criterio que quieras usar en salud mental.

Cómo se decide. Un modelo de lenguaje (Google Gemini) lee el motivo de consulta y lo cruza con las especialidades y la disponibilidad de cada psicóloga. Con eso prepara una propuesta corta de candidatas que encajan con el caso y que además pueden atenderlo.

 Qué papel tiene la persona. La sugerencia no la ve el paciente. Le llega a la coordinadora de la plataforma, que revisa las propuestas y elige a mano a qué psicóloga se asigna el caso. La IA le ahorra leer cada motivo de consulta comparándolo con todo el equipo, y la decisión la sigue tomando alguien que conoce a las profesionales y puede tener en cuenta cosas que no aparecen en ningún perfil.

Lo planteamos así desde el principio. En salud, una asignación equivocada le cuesta mucho al paciente, y que una persona con criterio revise cada propuesta es lo que permite usar IA en esa parte del proceso con tranquilidad.

El segundo caso es una plataforma para una comunidad de nómadas digitales, en su versión inicial de 2025. Aquí las decisiones son más pequeñas y frecuentes (a qué destino ir después, qué hacer allí, a qué evento apuntarse) y el catálogo crece con lo que aporta la propia comunidad.

Qué datos hay. Las fichas de eventos, destinos y actividades, las conversaciones de cada usuario con la plataforma por chat y su historial dentro de la comunidad, es decir, a qué eventos ha ido y por qué destinos ha pasado. En la conversación la persona cuenta qué busca, qué le ha gustado y qué no, con mucho más detalle del que daría marcando casillas en un formulario. El historial añade lo que no ha contado. 

Cómo se decide. Generamos embeddings de los eventos, los destinos y las actividades, y también de las conversaciones del usuario. Cuando alguien busca algo, el sistema combina todo eso para encontrar destinos y propuestas que encajen con lo que busca, aunque no los haya mencionado. Si alguien ha hablado de surf, de trabajar por las mañanas y de evitar las ciudades grandes, el sistema puede proponerle un destino que no conocía y que cumple todo eso. 

Cómo aprende de cada persona. A medida que un nómada va a eventos y pasa por destinos, ese recorrido también entra en la búsqueda. Por ejemplo, no se le proponen sitios en los que ya ha estado, y lo que ha ido eligiendo ayuda a ajustar qué tipo de planes y lugares le encajan. 

Este planteamiento funciona desde la primera conversación y mejora con el uso, así que no hubo que esperar a que la comunidad acumulara meses de actividad para que las recomendaciones fueran útiles.

El arranque en frío (cold start) es lo que pasa cuando el recomendador necesita datos de comportamiento y todavía no los hay, porque la plataforma es nueva, porque el usuario acaba de llegar o porque el elemento se ha publicado hoy. Pasa en casi todos los proyectos, así que conviene tenerlo previsto desde el principio.

• Empezar con reglas y contenido. Una primera versión con reglas claras (disponibilidad, especialidad, fechas) y similitud de contenido ya resulta útil y se puede explicar. 
• Dejar que la persona cuente lo que busca. Un motivo de consulta o una conversación dan más información que un formulario largo que muchos no terminan. Con modelos de lenguaje, ese texto libre se puede aprovechar desde el primer mensaje.
• Usar la popularidad con cuidado. Lo más visto es un buen punto de partida, pero si se usa solo acaba recomendando siempre lo mismo y lo nuevo no llega a verse.
• Guardar las señales desde el primer día, aunque todavía no se usen. Si más adelante quieres añadir filtrado colaborativo, vas a necesitar meses de historial.

En la plataforma de nómadas, lo que más vueltas nos dio fue combinar las conversaciones por chat con la recomendación. En cualquier conversación hay una parte que no es una búsqueda: es charla, comentarios sueltos o preguntas que no tienen que ver con elegir un plan. Si se trata igual que el resto, mete ruido en lo que se recomienda.

También aparecían eventos que podían interesarle a la persona, pero en un destino que no le encajaba. Para resolver los dos problemas hubo muchas idas y venidas ajustando cuánto pesaba cada cosa en el resultado: la conversación, el historial, el destino y el propio evento. Cada cambio de pesos mejoraba unos casos y podía empeorar otros, y eso es difícil de ver si se revisa caso a caso.

Si no se mide, con el tiempo nadie sabe bien por qué el sistema recomienda lo que recomienda y cuesta mucho cambiarlo.

Una métrica de resultado, definida antes de lanzar. La que salga de pensar cómo vas a saber si la recomendación ha acertado: continuidad después de la primera sesión, reservas o inscripciones a partir de lo recomendado. El clic sirve para depurar, pero no indica si la recomendación fue buena. 

Algo con lo que comparar. Conviene medir el sistema frente a lo que había antes, o frente a algo sencillo como ordenar por popularidad. Si el recomendador no mejora claramente ese orden, probablemente no compensa la complejidad que añade. Cuando hay volumen suficiente, una prueba A/B es la forma más fiable de saberlo. 

Un conjunto de pruebas con resultados esperados. Consiste en reunir una serie de casos reales o representativos (una conversación, un historial, una búsqueda) y dejar escrito qué debería recomendarse en cada uno. Cada vez que se cambia un peso, un prompt o el modelo, se pasa el conjunto entero y se ve qué casos mejoran y cuáles empeoran. Para ajustes como los de la plataforma de nómadas es lo más útil que hay, porque permite comparar modelos y cambios con datos en lugar de impresiones. Herramientas como Langfuse ayudan mucho con esto: guardan la traza de cada recomendación (qué entró, qué hizo el modelo y qué salió), permiten mantener esos conjuntos de pruebas y comparar versiones entre sí. Además es de código abierto y se puede alojar en tu propia infraestructura, algo que conviene cuando los datos son sensibles. 

Revisión humana. Alguien que conozca el negocio debería leer cada cierto tiempo una muestra de recomendaciones reales, porque hay errores que las métricas agregadas no muestran y que una persona detecta enseguida. Cuando alguien valida cada propuesta, como la coordinadora en La Psicóloga en Casa, sus decisiones también sirven para medir: cada vez que elige a alguien fuera de la lista sugerida, merece la pena revisar por qué.

Una recomendación que se puede explicar es más fácil de mantener. A un usuario, una línea del tipo «porque buscas un sitio tranquilo para trabajar y te interesa el surf» le da confianza y le permite corregir al sistema. A una coordinadora, saber por qué se propone a cada psicóloga le ayuda a decidir más rápido y a ver cuándo una propuesta no tiene sentido. Al equipo técnico, poder consultar qué datos ha usado cada recomendación le permite encontrar errores y responder cuando alguien pregunta por qué ha salido algo raro.

Por eso preferimos sistemas que se puedan explicar y medir aunque sean algo menos sofisticados. Para nosotros, eso es una IA responsable y medible: un sistema que el cliente entiende, puede auditar y puede mejorar sin depender de nosotros para cada pregunta.

Todo recomendador trabaja con datos personales, así que conviene dejar por escrito antes de empezar qué se guarda, dónde se procesa y durante cuánto tiempo.

Con fichas de catálogo y datos de uso, normalmente basta con informar bien, guardar solo lo que se va a usar y permitir que la persona desactive la personalización. Las conversaciones por chat requieren más cuidado, porque la gente cuenta en ellas más de lo que pondría en un formulario. 

Con datos de salud el nivel de exigencia es mucho mayor. El RGPD los considera una categoría especial, lo que implica una base legal reforzada, procesar solo lo imprescindible y cuidar cada paso por el que pasa el dato. Si el texto del paciente se envía a un modelo de lenguaje externo, hay que usar una versión con garantías contractuales. En nuestros proyectos usamos Gemini en su modalidad empresarial de pago, que está cubierta por el acuerdo de tratamiento de datos de Google Cloud con cláusulas contractuales tipo, y en la que los datos no se usan para entrenar modelos ni los revisan personas. 

La región donde se procesan los datos es otra decisión que conviene tomar al principio. Si tus usuarios están en Europa, procesar sus datos en Europa simplifica mucho la relación con el equipo legal y con los propios usuarios, y es más fácil configurarlo al empezar que cambiarlo después.  

Un recomendador básico, que pasa unos pocos datos a un modelo de lenguaje y recibe la respuesta en un formato estructurado, puede salir por 2.000 o 3.000 €. Si hace falta generar embeddings y montar algo tipo RAG, el proyecto cambia de escala: hay que añadir una base de datos vectorial, generar los embeddings del catálogo y de lo que cuenta cada usuario, hacer las búsquedas sobre ellos e integrar algo como Langfuse para tener trazabilidad de todo. En ese caso, el mínimo está en torno a 10.000 €.

En nuestra experiencia, el algoritmo es una parte pequeña del coste. La mayor parte se va en preparar el catálogo para que se pueda comparar, registrar bien las señales, montar la medición y ajustar el sistema durante las primeras semanas de uso real. Sobre dónde suelen desviarse los presupuestos en proyectos a medida, tenemos un artículo sobre por qué se desvían los presupuestos de desarrollo de software.

Nosotros empezaríamos por escribir en una frase qué decisión se quiere facilitar, quién la toma al final y cómo se va a saber si ha salido bien. Con eso ya se puede valorar si hace falta un recomendador, unos filtros mejores o una combinación de los dos.

Si tu plataforma tiene más contenido del que tus usuarios encuentran, cuéntanoslo y lo vemos.