Cómo clasifiqué 3,3 millones de búsquedas internas de moda con un LLM

Acaba de salir el estudio de tendencias de búsqueda interna en eCommerce de moda que he hecho en colaboración con Doofinder. Analizamos cómo busca la gente dentro de las tiendas online de moda españolas, es decir, qué tipos de producto pide, con qué atributos afina, cuánto pesa la marca y qué ocasiones mueven la compra.

En este post explico el “behind the scenes”, de cómo se pasa de un CSV con 3,3 millones de búsquedas (con criterios de privacidad aplicados) a datos con los que tomar decisiones. Creo que las elecciones metodológicas pueden ser útiles para más personas que se encuentren con un tarea de clasificación similar. He analizado, clasificado y clusterizado muchísima más información de formas muy diferentes, pero en esta ocasión os cuento el porqué de las decisiones que tomé.

La raw data inicial 

Se me proporcionaron las búsquedas que los usuarios escribieron entre enero y abril de 2026 en los buscadores internos de tiendas que vendían moda en España y que usan Doofinder. Para proteger la privacidad y quedarnos solo con demanda representativa, entraron únicamente las queries con al menos 50 búsquedas y presentes en al menos 5 tiendas distintas. Así que nada de long tail de una sola tienda que pueda identificar a un comercio o a una persona.

Tras normalizar (minúsculas, espacios, y agregación de variantes idénticas) quedaron 7.790 queries únicas que suman 3,3 millones de búsquedas, así que “easy peasy lemon squeezy". Ley de Zipf as its max.

La mitad de la "moda" no era moda

Al abrir la data me encontré con queries tipo "omega 3", "freidora de aire" y "colágeno" conviviendo con "vestidos" y "botines". El motivo es que muchas tiendas de moda no venden solo moda. Se agrupan en Doofinder por su vertical principal, pero su catálogo es mixto (parafarmacia, electrodomésticos, alimentación).

Así que se clasificó el corpus entero, etiquetando lo que es moda de lo que no. El modelo (Claude Sonnet, luego explico por qué ese y no otro) etiquetó cada query con un campo de tres estados: es moda, no es moda, o no lo sé. "Vestidos" es moda, "omega 3" no lo es, y "azul marino" es un no lo sé. Así que saqué fuera todo lo confirmado como no-moda, que resultó ser un 45% del volumen (1,48 millones de búsquedas) y el resto de búsquedas (1,83 millones) es sobre los que trabaja el informe.

De esos 1,83 millones, 1,15 millones de búsquedas tenían un tipo de producto de moda concreto asignado, y solo ellas entran en los rankings de tipos, subtipos, atributos y marcas. Las ambiguas (colores sueltos, ocasiones a secas, números sin resolver) no pueden rankear productos porque no nombran ninguno, pero tampoco las desecho, ya que pasan a alimentar los ejes transversales del informe, como el de ocasión de compra.

Esta fue la decisión de limpieza más importante de todo el proceso.

Por qué no usamos clustering

Cuando cuentas que has clasificado miles de queries, siempre te pregunta alguien que ¿por qué no clustering con embeddings y a correr? Porque la tarea era entender qué pide el usuario y no agrupar textos parecidos, me explico:

• Una query no es una categoría, son varias facetas a la vez. "Botas niña impermeables" lleva tipo de producto, género y atributo en tres palabras. Un embedding te da una proximidad a un punto del espacio y nosotros necesitábamos descomponer cada query en producto, marca, atributos, género y ocasión. Para eso harían falta tantos sistemas de similitud como facetas.
• La mayoría de queries de buscador interno tienen de 1 a 3 palabras. Por lo que muchas veces no hay contexto semántico del que agarrarse. El embedding de "530" no significa absolutamente nada, y saber que "jordan" implica calzado en este contexto no es una cuestión de similitud de texto.
• La similitud coseno nunca se abstiene. Siempre te devuelve un vecino más cercano. Con la mitad del dataset siendo no-moda, "omega 3" habría aterrizado en el nodo de moda que le pillara más cerca, salvo que calibres umbrales a mano para cada caso. Un LLM puede responder "esto no es moda" o "no lo sé", y esa honestidad era justo lo que necesitábamos para la limpieza que he contado arriba.
• Los topics son inestables y hay que bautizarlos a posteriori. Para una foto puntual puede valer, pero este estudio está diseñado para repetirlo cada temporada y comparar. Y con no clusters que cambian con cada ejecución no puedes hacerlo.
• El coste era muy bajo. Tras limpiar eran 7.790 queries y la clasificación costó unos 5 dólares de API. El clustering con ML compensa cuando el volumen hace inviable pasar un LLM, y este no era el caso.

Clasificar contra una taxonomía cerrada

Ahora bien, un LLM se inventa categorías más rápido de lo que tardas en pedirlas. Por eso la clasificación fue contra un vocabulario cerrado, escogiendo para cada producto ser un nodo exacto de la taxonomía oficial de Google Shopping en español (la rama "Ropa y accesorios"), o null. Elegí esa taxonomía porque es un estándar de la industria, estable entre periodos y conocido por cualquiera que trabaje con feeds de producto.

Si has trabajado con feeds de Merchant sabrás que Google tiene un problema con la taxonomía de "Calzado", que es sólo un nodo. Para prendas distingue decenas de tipos de ellas, pero no tiene ni una sola familia de zapatos.

Así que la solución fue una faceta propia de subtipo, con la misma filosofía de vocabulario cerrado: 17 subtipos de calzado (botas, botines, sandalias, deportivas, tacones, cuñas...) y aproveché para añadir una veintena de ropa que Google tampoco separa a nivel comercial. Con sinónimos fusionados a una etiqueta canónica ("zapatillas" y "deportivas" son la misma familia) y con dos válvulas de escape, un "sin especificar" para lo genérico y "otro" cuando nada encaja.

Además del tipo de producto, el modelo extrae marca, atributos, género, ocasión y señales tipo rebajas o talla grande. Y trabaja con reglas estrictas:

• No bajar de nivel sin evidencia: "ropa" se queda en la categoría genérica, "vestidos de fiesta" baja hasta el nodo específico. El nearest-neighbor de un embedding no sabe hacer esta calibración de profundidad y un LLM instruido, sí.
• Prohibido inventar marcas. Si no hay marca clara = null.
• Prohibido adivinar con números sueltos (ahora llegamos a esto).
• Confianza: baja para queries ambiguas, truncadas o con ruido.

Cómo medir el error

Antes de clasificar nada, etiqueté a mano un golden set de unas 200 queries, con casos fáciles y trampas (erratas, números, marcas ambiguas, no-moda). Con ese golden set hice un benchmark de 3 modelos de Claude sobre el tipo de producto:

En marca y atributos, Sonnet y Haiku igualaban o superaban a Opus. Con los tres modelos en una horquilla de pocos puntos, elegimos Sonnet: unos 5 € por ejecución frente a unos 30 € de Opus. Para extracción estructurada contra vocabulario controlado no hace falta el modelo más caro y un error en torno al 5% es super asumible para un estudio de tendencias.

Qué hice con las queries de números sueltos

"530", "501", "9060"... quién tenga una tienda de calzado sabe que la gente busca modelos de zapatillas escribiendo solo el número. Al modelo le prohibimos adivinar aquí, porque un LLM te dirá encantado que "501" es Levi's aunque en tu tienda solo tenga New Balance.

Así que lo comparé con el propio dataset y tienda para desambiguar, si existen queries hermanas de esa tienda como "new balance 530", el número hereda esa marca y ese tipo de producto por votación. Si no hay evidencia fuerte interna, el sistema se abstiene, y ese volumen se reportaría como no resuelto en vez de rellenarse con una alucinación.

Reproducible por diseño

Todo el pipeline corre con un comando y se cachea cada fase por periodo: clasificación, números, subtipos y ocasiones. De forma que al re-ejecutarlo contra otro periodo, no reharía la clasificación de una query, asegurando el máximo determinismo posible. Y la agregación final que produce los rankings del informe es código determinista.

Así podremos repetir el análisis con los datos de la siguiente temporada, con la misma taxonomía y el mismo baremo de error, y que las comparaciones tengan sentido a lo largo del tiempo.

Mira tu propio buscador

Llevo años haciendo Site Search Analysis, desde que se hacía con los logs del servidor, gracias a lo que aprendí en el famoso libro de Search Analytics for Your Site de Louis Rosenfeld, y he dado varias charlas sobre ello desde 2014 en escuelas de negocio y eventos (esta es de 2016 en el eshow).

El buscador interno es para mi la fuente de first-party data más limpia y potente que tiene un ecommerce. Es literalmente tu cliente escribiendo con sus palabras lo que quiere, y muchas veces no encuentra. Te desvela patrones de navegación, te ayuda a definir una arquitectura, te muestra errores de usabilidad y de experiencia de usuario… Es una data brutal. Los patrones agregados del sector están en el informe, pero la mina de verdad la tienes en los informes de búsqueda de tu propia tienda. Y, si no tienes un buscador potente, usa Doofinder 🙂