Machine learning frente a sistemas de recomendación con LLM: cuándo gana el ML clásico

Para la mayoría de los problemas de recomendación, un sistema de recomendación con machine learning — filtrado colaborativo, puntuación basada en contenido o factorización de matrices — gana a un LLM en todos los ejes que importan para sacar un producto: coste por petición, latencia p99, explicabilidad y comportamiento en el arranque en frío. Recurre a un LLM solo cuando el resultado sea texto genuinamente nuevo que el usuario deba leer. Todo lo demás es ordenar elementos conocidos, y el ML clásico los ordena mejor, más barato y de forma defendible.

Construimos recomendadores para productos de bienestar — de los que sugieren un cambio de comida, una pauta de sueño, un ejercicio o un suplemento en una pantalla que el usuario abre cada mañana. Hemos enviado ambas arquitecturas. Esta es la decisión que tomamos de verdad, término a término, con los números que la sostienen.

Machine learning frente a un sistema de recomendación con LLM: primero, las definiciones

La mitad de la confusión en estos debates viene de un vocabulario descuidado. Así que, con precisión:

• El filtrado colaborativo recomienda elementos encontrando usuarios que se comportaron como tú y mostrando lo que les gustó. "Quien registró este entrenamiento también registró aquel." Necesita un historial de interacciones y nada sobre los propios elementos.
• El filtrado basado en contenido recomienda elementos similares a los que ya consumiste, usando características del elemento — los macros de una receta, las etiquetas de un artículo, el mecanismo de un suplemento. Necesita metadatos de los elementos y nada sobre otros usuarios.
• La factorización de matrices es el motor tras el filtrado colaborativo moderno. Tienes una matriz gigante y casi vacía de valoraciones o interacciones usuario-por-elemento; la factorización la descompone en dos pequeñas matrices densas (vectores de usuario y vectores de elemento) cuyo producto predice las celdas que faltan. Netflix la popularizó hacia 2009; sigue siendo excelente.
• Un recomendador con LLM usa un modelo de lenguaje grande — ya sea dándole un perfil de usuario y pidiéndole sugerencias, ya sea proyectando elementos y consultas en un espacio vectorial común para recuperación semántica. El primero es generativo; el segundo es, en realidad, filtrado basado en contenido vestido de transformer.

La versión corta: una recomendación casi nunca es un problema de generación de texto. Es un problema de ordenación sobre un conjunto finito de candidatos que ya es tuyo. Visto así, el LLM deja de parecer la herramienta obvia.

Eje 1 — Coste: la partida por petición

Un ranker con gradient boosting entrenado o un modelo de factorización de matrices cuesta prácticamente nada por petición. Es un producto escalar, o unos cientos de divisiones de árboles, ejecutándose en el mismo proceso que sirvió la página. Sin salto de red, sin contador de tokens.

Un recomendador con LLM es un coste recurrente y medido en cada carga de pantalla. Toma una app de bienestar con 30 000 usuarios activos diarios que ven sugerencias cinco veces al día: son 150 000 inferencias al día, 4,5 millones al mes. Incluso a una fracción de céntimo por llamada, tras contar el contexto de entrada, los tokens de salida y los reintentos que necesitarás para JSON malformado, estás pagando mensualmente por algo que un modelo de un solo archivo hace gratis. El coste marginal del modelo clásico es error de redondeo; el coste marginal del LLM crece linealmente con tu éxito. El crecimiento no debería ser un incidente de costes.

Eje 2 — Latencia: el presupuesto que no recuperas

Un panel de bienestar quiere renderizarse muy por debajo de los 100 ms. Nuestros rankers en-proceso devuelven candidatos puntuados y ordenados en menos de un milisegundo — la recomendación no está en la ruta crítica, es ruido en el presupuesto de renderizado.

Una llamada a un LLM tarda de cientos de milisegundos a varios segundos, y la cola es brutal: la p50 puede ser aceptable mientras la p99 revienta por completo tu presupuesto. Puedes transmitir tokens para disimularlo, pero no puedes transmitir una lista ordenada que el usuario necesita antes de decidir qué tocar. Así que recurres a la caché. Ahora mantienes una estrategia de invalidación de caché para recomendaciones que cambian con cada comida registrada — resolviendo un problema difícil que creaste al elegir la herramienta equivocada. El modelo clásico nunca tuvo el problema.

Eje 3 — Explicabilidad: la pregunta que todo usuario acaba haciendo

"¿Por qué me estáis mostrando esto?" En un contexto regulado o cercano a la salud, esto no es un lujo — es la diferencia entre un producto defendible y una responsabilidad legal.

Un recomendador por puntuación responde con números. Nuestro ranker de bienestar puntúa cada candidato en unos ejes explícitos — peso de evidencia (anotado una vez por un clínico, ECA > cohorte > informe de caso), delta personal (cuán lejos está el usuario del objetivo clínico para la métrica en cuestión) y coste de adherencia (la fricción que añade la sugerencia). Multiplicar, ordenar, quedarse con la cima. Cada sugerencia se descompone en tres números que podemos mostrar, registrar y reproducir.

Hazle la misma pregunta a un LLM y obtienes un párrafo fluido que suena a una razón pero no es la causa real del resultado — es una racionalización a posteriori generada por el mismo proceso estocástico. No lo puedes probar con pruebas unitarias. No lo puedes comparar entre versiones del modelo. No lo puedes poner ante un clínico para que firme la lógica, porque no hay lógica, solo pesos que no te pertenecen. Para el trabajo accesible y de dispositivos médicos de Clase I que hacemos bajo el MDR 2017/745 de la UE, "lo dijo el modelo" no es una respuesta.

Eje 4 — Arranque en frío: el problema que todos subestiman

El arranque en frío es el momento más difícil del recomendador: un usuario recién llegado sin historial, o un elemento recién llegado que nadie ha tocado. Es donde el filtrado colaborativo ingenuo se desmorona — sin interacciones, no hay nada que factorizar.

Esta es la matización que decide la arquitectura:

• Arranque en frío de usuario nuevo. La puntuación basada en contenido lo maneja con elegancia — puntúas el conjunto de candidatos contra lo poco que sabes (respuestas de onboarding, una sola métrica registrada) y mejoras a medida que llegan los datos. Un LLM también puede razonar a partir de un perfil escaso, y es el único sitio donde tiene una ventaja genuina. Pero un ranker basado en contenido ajustado a mano te da el 90% de ese beneficio al 0% del coste, y controlas exactamente qué pondera.
• Arranque en frío de elemento nuevo. Aquí es donde brillan los LLM y los embeddings y el filtrado colaborativo puro no puede: una receta nueva con cero interacciones aún tiene características — ingredientes, macros, etiquetas. Proyéctala en un embedding y la similitud basada en contenido la coloca al instante. No necesitas un modelo generativo para esto; un sentence-transformer de 90 MB produce embeddings que baten a un LLM de frontera en la mayoría de los benchmarks de recuperación, a la milésima parte del coste.

La conclusión honesta: la parte del arranque en frío que te tienta hacia un LLM se resuelve mejor con embeddings más características de contenido, que es ML clásico con un extractor de características moderno — no interrogando a un modelo de chat en cada petición.

La caja de herramientas, por orden de prioridad

1. Puntuación ponderada con coeficientes ajustados a mano. Aburrida, eficaz, dos fines de semana para enviarla. Máximamente explicable. Empieza aquí.
2. Árboles con gradient boosting (XGBoost / LightGBM) sobre etiquetas de interacción. El mejor ROI en ML aplicado de la última década. Entrena en un portátil, capta interacciones de características no lineales que tus pesos manuales pierden.
3. Factorización de matrices cuando ya tienes historial real de usuario-elemento. El motor clásico del filtrado colaborativo; sigue siendo el estándar de la práctica para el recall de "usuarios como tú".
4. Embeddings / sentence-transformers para similitud semántica y arranque en frío de elemento nuevo. Es tu capa de recall basada en contenido.
5. Bandits contextuales cuando necesitas explorar además de explotar y aprender en línea a partir de los clics.
6. Un LLM — solo cuando el resultado sea prosa genuinamente nueva que el usuario deba leer.

Un recomendador maduro suele ser generación de candidatos (filtrado colaborativo + recall basado en contenido sacan unos cientos de candidatos) seguida de una fase de ordenación (un modelo con gradient boosting los puntúa). Dos fases, ambas ML clásico, ambas explicables, ambas rápidas.

Entonces, ¿cuándo gana de verdad el LLM?

Tres casos legítimos, y comparten una forma — el LLM produce texto, no una decisión:

• Generación abierta. "Escríbeme una semana de entrenamientos con estas restricciones." No hay un conjunto finito de candidatos que preautorar, así que la ordenación no aplica.
• Interfaz en lenguaje natural. El usuario pregunta en prosa; el LLM la traduce a una consulta contra un sistema determinista; la respuesta viene de ese sistema. El LLM es el traductor, no el oráculo.
• Explicación anclada. El ranker clásico elige la sugerencia; el LLM escribe la frase que explica por qué, anclada en los tres números del ranker. Una alucinación ahora te cuesta una frase torpe, no una recomendación clínica.

Fíjate en el patrón: en todos los casos ganadores, el LLM está aguas abajo de, u ortogonal a, la decisión de ordenación. Nunca es el recomendador.

El orden de envío

Si tienes en las manos una especificación que dice "sugerencias con IA", haz esto:

1. Lista los candidatos. Si no puedes enumerarlos, no tienes un problema de recomendación — tienes un problema de contenido. Resuélvelo primero.
2. Elige tres ejes de puntuación. Ajusta los pesos a mano durante una semana. Envía.
3. Registra cada sugerencia mostrada y cada una sobre la que se actuó. Es tu conjunto de entrenamiento; solo lo consigues enviando.
4. Tras cuatro a seis semanas de datos, entrena un modelo con gradient boosting sobre los registros y retira los pesos manuales. Añade factorización de matrices y embeddings a medida que crecen tu historial y tu catálogo.
5. Solo entonces, si aún necesitas prosa nueva, añade un LLM — para explicar, no para decidir.

Enviarás más rápido, gastarás menos, dormirás mejor y — la parte que importa — podrás responder a la única pregunta que cuenta cuando un usuario pregunta por qué recibió esa sugerencia: aquí están los tres números, y aquí está lo que significan. Ese es todo el argumento a favor del machine learning sobre un recomendador con LLM, en una frase.

Es la misma disciplina tras los recomendadores de bienestar que construimos, las analíticas centradas en la privacidad que operamos y la tienda de chocolates que enviamos para Delicious Diamonds: elegir el modelo más simple que responde a la pregunta que te pueden pedir que defiendas. Si estás mirando una funcionalidad de recomendación y la especificación dice "deja que la IA se encargue", estaremos encantados de disuadirte.