Yo dirigió Dynamic Product Ads en Twitter, donde comparamos millones de usuarios a cientos de millones de productos de comercio electrónico en tiempo real. La salida fue los principales 5-6 productos que cada usuario tenía más probabilidades de comprar. El sistema utilizó incorporaciones de productos y usuarios con modelos ML clásicos para servir anuncios personalizados a escala de Twitter. Vimos una mejora del 15-18% en el CTR y una mejora del 12% en las tasas de conversión en comparación con los anuncios de marca. Esto fue hace unos años. pero ahora, todo el mundo está hablando de la IA y los grandes modelos de idiomas como si revolucionaran todo. Por lo tanto, estaba reflexionando sobre si hoy construiría los anuncios de productos dinámicos, ¿utilizaría los LLM? y más importante, ¿qué no cambiaría en absoluto, y por qué? La respuesta: Yo usaría LLMs para alrededor del 20% del sistema, específicamente para generar incorporaciones, y mantener todo lo demás igual. Nuestro enfoque original El problema a la mano: recomendar productos a un usuario que es más probable que haga clic y compre, mientras que están desplazando rápidamente su línea de tiempo. Había millones de productos para elegir y anunciantes. Más allá de eso, había millones de usuarios desplazando al mismo tiempo. El sistema tuvo que hacer predicciones para millones de usuarios dentro de la latencia sub-milisegundo. El canal de servicio de anuncios tendría que completar la predicción en menos de 50 milisegundos, al máximo. El enfoque era muy manual (para al menos 2022). Productos embebidos Usamos los metadatos de cada producto, como título, descripción, categoría, precio, etc., y los codificamos en un espacio vectorial denso de 128 dimensiones. Usuarios de Embeddings Los usuarios estaban representados por vectores basados en señales como su participación en la plataforma, información de perfil y compras pasadas. El modelo de coincidencia En el momento de la inferencia, usaríamos un enfoque de dos etapas. En primer lugar, ejecutaríamos una búsqueda rápida aproximada del vecino más cercano para recuperar productos candidatos cuyas incorporaciones estaban cerca de las incorporaciones de los usuarios. Luego, usaríamos un árbol de decisión impulsado por gradientes para puntuar a esos candidatos, incorporando características adicionales como reciente, señales de precios y contexto como el tiempo del día. El modelo y ANN (el vecino más cercano aproximado) eran explicables, debugables y, lo más importante, lo suficientemente rápidos para la escala de Twitter. ¿Cómo me acercaría a esto hoy? Si yo estuviera construyendo este sistema hoy, aquí está lo que realmente cambiaría. Mejores incorporaciones de productos con codificadores LLM La mayor mejora sería en la generación de mejores incorporaciones de productos. Los modelos modernos de gran lenguaje son notablemente buenos en comprender el significado semántico y el contexto. En lugar de unir las descripciones de productos (la mayoría de las cuales eran bastante malas al principio), usaría un codificador basado en LLM para generar incorporaciones de productos. Esto es importante porque un producto titulado “sapatos de correr” sería semánticamente cercano a “sneakers para correr”, aunque no comparten las palabras exactas. Tratar esto sin esfuerzo. all-MiniLM-L6-v2 Una vez tuvimos una entrada en el catálogo de productos de Nike titulada "Air Max 270 React" que nuestras incorporaciones de 2022 no podían coincidir con los usuarios que buscaban "zapatos de running" o "zapatos deportivos" porque no había una superposición de palabras clave.El producto recibió 35-40% menos impresiones que artículos similares en su primera semana hasta que recopilamos suficientes datos de compromiso. Mejora en el manejo de frío Los LLMs también harían que el manejo de inicio frío sea un poco mejor. Cuando un nuevo producto aparece en un catálogo, LLM puede extraer señales ricas de las descripciones de productos, reseñas e imágenes para generar una incorporación inicial razonable. De la misma manera, para los nuevos usuarios con un historial de compromiso escaso, los codificadores modernos pueden entender mejor su información de perfil y los tweets iniciales (si lo tienen) para crear representaciones significativas. Entonces, ¿dónde se encajarían los LLM en la arquitectura real? Enfoque híbrido Todavía usaría el ML clásico para almacenar y servir capas reales. Feature LLM or Classic LLM-based encoder to generate user and product embeddings LLM Match embeddings to generate candidate products per user Classic Final scoring and ranking Classic Encoder basado en LLM para generar incorporaciones de usuarios y productos LLM Incorporaciones compatibles para generar productos candidatos por usuario Clásico Clasificación y ranking final Clásico ¿Por qué usar modelos clásicos para la puntuación? Las razones son la latencia, el coste y la explicabilidad. Los LLM no pueden predecir productos para millones de usuarios en menos de 10 milisegundos. Son un overkill para combinar características numéricas y tomar una decisión de clasificación. Los modelos clásicos lo harían en microsegundos. A escala de Twitter, la diferencia entre 1ms y 10ms tiempo de inferencia se traduce en millones de dólares en costes de infraestructura y caídas mensurables en el compromiso del usuario. Ejecutar la inferencia LLM para cada solicitud de predicción costaría 50-100 veces más que nuestro enfoque clásico. ¿Qué pasa con la creación de Ad Copy? Hay un montón de hype en Internet sobre el uso de LLMs para generar copia de anuncio personalizado en el vuelo o para razonar sobre la intención del usuario en tiempo real. Generar copia de anuncios con LLMs introduce riesgos inaceptables como alucinaciones sobre características de productos, marca inconsistente, y contenido difícil de revisar en esta escala. El sistema tendría que mostrar millones de variaciones de anuncios por día, y no habría manera de revisarlos para la precisión y la seguridad de la marca. Una afirmación alucinada sobre un producto como "protestante" cuando no es, o "aprobado por la FDA" cuando no es, crearía responsabilidad legal. El riesgo no justifica el aumento marginal en el compromiso. ¿Qué no cambia? Si el sistema utiliza embeddings de 2022 o LLMs de 2026, el desafío fundamental sigue siendo el mismo: inferir lo que alguien quiere de las señales ruidosas. Alguien que tweets sobre zapatos de correr puede ser una compra de corredores de maratón para su siguiente pareja, o un observador casual que acaba de ver una carrera en televisión. Este problema necesita buenos datos para resolver, ingeniería de características pensativa y mucha experimentación. Understanding user intent son no negociables. A escala, cada milisegundo cuenta. Los usuarios abandonarían experiencias que se sienten lentas. Los sistemas de anuncios no pueden ralentizar la carga de la línea de tiempo. He visto varios sistemas de infraestructura ML desmoronarse en las pruebas A/B porque añadieron 100ms de latencia a un sistema bien oleado. El modelo podría ser mejor, pero el requisito de latencia lo rompe todo. Latency requirements Problemas como el inicio frío para nuevos productos o usuarios, y problemas de calidad de datos cuando los catálogos tienen descripciones de productos faltantes o incorrectas, siguen ahí.Estos problemas son ortogonales a la arquitectura del modelo y requieren pensamiento de diseño del sistema, y no la construcción de arquitectura del modelo. Last-mile problems Un equipo que puede ejecutar 10 experimentos por semana con un modelo más simple superará constantemente a un equipo que ejecuta 1 experimento por semana con un modelo muy sofisticado. La capacidad de probar rápidamente, medir los resultados e iterar es más valiosa que las mejoras marginales en la calidad del modelo. Cuando lanzamos Dynamic Product Ads, ejecutamos 3-4 experimentos por semana. Testamos diferentes dimensiones de incorporación, diferentes algoritmos ANN y diferentes características en el modelo de puntuación. La mayoría de los experimentos fracasaron. Pero los que trabajaron se agudizaron. Esa velocidad significó más que elegir la arquitectura del modelo “perfecto”. Iteration speed La verdadera pregunta es: ¿dónde está la botella? Para ser honesto, la mayor parte de la discusión “cómo lo construirías hoy con la IA moderna” pierde el punto. La pregunta no debería ser lo que es posible con la nueva tecnología. Para nosotros, la barrera de botella nunca se trató de la calidad de las incorporaciones. Se trataba de comprender la intención del usuario, manejar problemas de calidad de datos en los catálogos de productos, y gestionar problemas de inicio frío, así como construir sistemas que podrían manejar la escala. Si yo estuviera construyendo este sistema hoy, gastaría el 20% de mi esfuerzo en "utilizar el LLM para generar mejores incorporaciones" y el 80% en los mismos problemas de escala, calidad de datos, experimentación y comprensión de la intención del usuario. La opinión impopular La industria de la tecnología ama las narrativas revolucionarias. Hubo un hype similar alrededor de blockchain y Web3 hace unos años. Pero la verdad es que la mayoría de los sistemas de ML de producción funcionan, escalan y ganan dinero. El enfoque revolucionario de usar LLM haría una mejora del 5%, pero sería 10 veces más lento y 100 veces más caro. La IA moderna es verdaderamente valiosa cuando se aplica de forma pensada a las barreras de botella, no como un reemplazo para todo el sistema que ya funciona.
