La búsqueda en el comercio B2B tiene un secreto incómodo: el algoritmo de ranking rara vez es el problema.
\nCuando los resultados son malos, los equipos tiran de las palancas divertidas. Boosts, sinónimos, embeddings, rerankers y, últimamente, la comprensión de consultas con LLM. Yo mismo he tirado de todas esas palancas. La semana pasada hice lo poco glamuroso en su lugar: volqué todos los registros de productos de cuatro índices de búsqueda en producción —775 051 registros de cuatro distribuidores B2B en HVAC, plomería, suministro industrial y fijaciones— y audité los datos en sí. Usé doce agentes de IA ejecutándose en paralelo, cada uno asignado a una dimensión: cobertura, calidad del texto, números de parte, marcas, precios, especificaciones, categorías, medios, duplicados.
\nLo que volvió no sorprendería a nadie que haya trabajado en el catálogo de un distribuidor, y sería impactante para quien no lo haya hecho. Pero lo que se me quedó grabado es esto: la solución ya está publicada. Amazon, DoorDash e Instacart han pasado dos años documentando, en blogs públicos de ingeniería, exactamente cómo usan los LLM para limpiar, etiquetar y enriquecer catálogos desordenados a escala. La distribución comercial, en su mayoría, no se ha dado cuenta. Lo cual es extraño, porque sus catálogos son más desordenados, sus consultas valen más (un contratista ordenando un condensador de $4 000, no un almuerzo de $12) y el tamaño de sus catálogos hace que la economía sea más sencilla.
\nAsí que esta publicación es ese manual, adaptado para la distribución comercial: los problemas de datos que rompen la búsqueda B2B, cómo encontrarlos esta tarde con un agente de programación, cómo solucionarlos con LLM incluyendo la categorización UNSPSC, y cuánto cuesta todo. Spoiler del último punto: menos de lo que imaginas por dos órdenes de magnitud.
\nAlgunas de las cosas que han publicado las empresas de marketplaces:
\nEl hilo conductor es fácil de pasar por alto: las victorias de los LLM están del lado del catálogo y son offline. Estas empresas enriquecen los datos antes de que llegue una sola consulta. Los sistemas de descubrimiento se dividen en un lado offline que construye artefactos (el catálogo, los índices, los embeddings) y un lado online que recupera y ordena sobre ellos, y casi todo el valor publicado de los LLM cae del lado offline. La capa de ranking solo puede ser tan buena como lo que se le alimenta.
\nAhora imagina el catálogo típico de un distribuidor de HVAC o plomería junto a eso. Está cosido a partir de exportaciones de ERP, hojas de cálculo de proveedores, feeds de grupos de compra y un parser de CSV que alguien escribió hace una década. Los "títulos" de producto son abreviaturas de factura escritas para los preparadores de pedidos del almacén. Y el tráfico de búsqueda que lo golpea es de los más densos en intención que existen: la mitad son números de parte exactos, el resto jerga del oficio como "3/4 cxc 90 ell". Honestamente, no se me ocurre un entorno mejor para este manual. Las consultas son valiosas, los datos son reparables y, con unos pocos cientos de miles de SKU, un pase completo de LLM sobre el catálogo cuesta cientos de dólares. No millones. Cientos.
\nAsí es la forma de la auditoría, porque querrás reproducirla:
\nflowchart TD\n D["Volcado crudo del catálogo<br/>(JSONL, un registro por línea)"] --> C1["Agentes de cobertura por catálogo<br/>tasas de nulo, distribuciones, campos muertos"]\n D --> C2["Agentes de dimensión<br/>texto · números de parte · marcas · precios<br/>especificaciones · categorías · medios · duplicados"]\n C1 --> S["Síntesis: hallazgos ordenados por<br/>severidad, con registros de ejemplo"]\n C2 --> S\n S --> F["Pipeline de corrección: reglas + enriquecimiento con LLM<br/>+ clasificación UNSPSC + compuertas de ingesta"]\n
Una nota sobre el formato antes de los prompts. Todo lo de abajo funciona sobre un volcado genérico: un objeto JSON por línea, cada uno con un id único y los campos del registro. Elasticsearch, OpenSearch, Solr, Algolia, Typesense, un PIM, una exportación simple de base de datos —no importa. Cada plataforma puede producir esta forma, y cada prompt aquí se ejecuta contra ella.
Lo peor que encontré no fueron datos malos que alguien escribiera. Fueron datos que el pipeline destruyó en el camino de entrada, sin decirle a nadie.
\nEstos catálogos construyen su texto de búsqueda principal en el momento de la ingesta, usando una regex scripteada que extrae dimensiones y unidades de los títulos de producto. En títulos largos, la regex supera el límite de complejidad del motor, el procesador falla y el registro se indexa de todos modos —con un campo de error que nadie lee y sin campo de búsqueda principal alguno.
\n![\"Documents](\"/assets/images/b2b-search-silent-failures.png\")
\nEn toda la flota, 52 570 registros estaban sentados en el índice, invisibles para la ruta principal de consultas. En el peor catálogo, eso es uno de cada siete productos. Ningún dashboard lo detectó porque nada falló. El pipeline devolvió éxito todo el día, todos los días, durante meses.
\nDos hallazgos más de la misma familia. El espejo desactualizado: un campo contiene la verdad (un mapa de derechos por cuenta) y un segundo campo aplanado lo refleja para filtrar. En un catálogo, el espejo había divergido en el 19,85 % de los registros —31 000 productos activos ocultos erróneamente de la búsqueda filtrada por cuenta. Y el catálogo congelado: un índice no se había actualizado en diez semanas mientras sus hermanos se actualizaban diariamente. El tiempo de actividad se monitoreaba. La actualización de los datos no.
\nLas correcciones son aburridas y ese es el punto. Alerta sobre la cobertura de campos derivados (campo derivado vacío mientras su fuente no lo está). No mantengas dos representaciones de un mismo hecho; deriva el campo filtrable en el momento de escritura. Vigila la actualización de los datos por catálogo como vigilarías el tiempo de actividad.
\nAquí está el prompt para encontrar todo esto en tu propio catálogo (Claude Code o codex exec; la mecánica al final):
Aquí está un volcado de mi catálogo de productos como archivos JSONL en ./dump/ —un registro JSON por línea, cada uno con un "id" único y los campos del producto. Mi definición de campo/esquema (si existe) está en schema.json.\n\nEscribe Python en streaming (no lo cargues todo en memoria) para encontrar fallas silenciosas del pipeline:\n1. Registros que lleven algún campo de error/excepción que el pipeline les estampó.\n2. Para cada campo DERIVADO (concatenaciones, variantes *_search, *_normalized): registros donde el campo derivado está vacío pero su campo fuente obvio no lo está.\n3. Pares de campos que parecen espejos el uno del otro (uno anidado/rico, uno aplanado/filtrable): cuantifica con qué frecuencia discrepan.\n4. La distribución de marcas de tiempo de actualización/indexación: ¿hay alguna porción del catálogo congelada mientras el resto se refresca?\n\nReporta cada hallazgo con conteos, % del catálogo, 5 ids de ejemplo, y si los registros afectados están activos/visibles. Ordena por severidad.Las verificaciones de nulo son la herramienta de calidad de datos que todos ya tienen. Los marcadores de posición las derrotan, porque un marcador de posición está poblado. Simplemente no es verdad.
\nMi ejemplo favorito: en un catálogo de 313K SKU, el campo de marca tenía 741 valores distintos y un 99,99 % de población. Suena saludable. El valor principal, en el 88,8 % de todos los registros, era "Approved Vendor". Un marcador de posición del ERP. La marca real más popular cubría el 0,3 % del catálogo. Así que cada faceta de marca, boost de marca y reescritura consciente de marca estaba efectivamente muerta para nueve décimas partes del catálogo, mientras que la UI de facetas ofrecía alegremente "Approved Vendor" como el filtro de marca #1.
\nUna vez que empiezas a mirar, estas cosas están en todas partes:
\n99999999.000000 en el 55 % de un catálogo. La mediana de precio de ese índice era de noventa y nueve millones de dólares."unknown" en 64 registros, que luego rankean para la consulta "unknown".true escrito en un campo de descripción de texto en 1 516 productos activos. El motor lo coaccionó a la cadena "true", lo que hizo que esos productos se pudieran encontrar buscando "true"."6.71E+11" —la notación científica de Excel, con 51 productos no relacionados compartiendo ese "identificador"— más 15 121 UPC adicionales a los que les falta su cero inicial. Excel vuelve a atacar.La lección que saqué de esta categoría: audita las distribuciones de valores top-N por campo, no las tasas de nulo. Un campo que está 100 % poblado puede ser 88 % basura, y ninguna verificación de nulo te lo dirá jamás. Luego pon en lista de bloqueo los centinelas en la ingesta, mapéalos a nulos reales con banderas explícitas has_price / has_real_image, haz aserciones de tipo en el límite, y valida los identificadores estructuralmente. Trata cualquier cosa que haya pasado por una hoja de cálculo como sospechosa.
Mismo volcado JSONL. Para cada campo en mi catálogo, calcula la distribución de valores top-20 (pase completo, en streaming).\n\nMarca: (a) cualquier valor único que cubra >10 % de los registros —candidatos a marcador de posición/centinela como "Approved Vendor", "unknown", 99999999, 0.0; (b) valores cuyo tipo difiere del tipo dominante del campo (booleanos en campos de texto, flotantes entre cadenas); (c) campos identificadores (UPC/EAN/GTIN/números de parte): valida checksum y longitud, marca notación científica, ceros iniciales eliminados, espacios en blanco/unicode incrustados, e identificadores compartidos por múltiples registros; (d) valores tipo categoría o línea de producto sentados en campos de marca.\n\nPara cada marca: conteo, % del catálogo, 5 ejemplos textuales con ids, y una regla de ingesta propuesta de una línea que lo habría rechazado.Los catálogos de distribuidores son escritos por ERP, no por merchandisers. El texto es taquigrafía de factura: PROPRESS 2-1/2X1 CXC RED CPLG, HC HX 18X8 W. En un catálogo, un tercio de los nombres de producto tenían menos del 60 % de palabras de diccionario. En otro, los campos crudos de nombre y descripción eran 100 % nulos —el texto solo existía dentro de blobs de búsqueda derivados, así que todo lo que leía los campos crudos (títulos de resultados, inputs de embedding, prompts de jueces de relevancia) no leía nada y nadie lo sabía.
![\"Field](\"/assets/images/b2b-search-field-coverage.png\")
\nEse mapa de calor es mi artefacto favorito de la auditoría. Cada uno de esos campos existe en cada esquema. Los números son cuánto de cada uno realmente contiene datos. La fila que me impacta es la de ML-descriptions: la capa de enriquecimiento que los esquemas prometían en cada registro estaba poblada en dieciocho documentos de 775 051. Dieciocho. Cada rama de "usa el enriquecimiento si está presente" en el pipeline de scoring era un no-op silencioso. El esquema es una aspiración; solo la cobertura es un hecho.
\nEsta categoría es donde el manual publicado aplica más directamente —la extracción de atributos de DoorDash, la generación offline de Instacart— y la sección de costos de abajo lo cotiza. Pero cuatro reglas importan en un negocio de números de parte, aprendidas en parte de lo que el intento de enriquecimiento anterior hizo mal:
\n{size, material, connection_type} para facetas.CXC, ELL, CPLG, "t-stat" pertenecen a la expansión de sinónimos a nivel de analizador, arreglada una vez. No pagues por reescribirlos en medio millón de registros.Mismo volcado. Evalúa la calidad del texto de los campos orientados al cliente (nombre, descripción corta/larga) con un pase completo en streaming:\n\n1. Cobertura de título efectivo: % de registros ACTIVOS con un nombre de visualización no vacío.\n2. Legibilidad: % de nombres en MAYÚSCULAS; % con menos del 60 % de tokens de palabras de diccionario (ensalada de abreviaturas); nombres de menos de 10 caracteres; descripciones de solo dígitos.\n3. Basura: marcado HTML/CMS, artefactos de codificación, notas operativas incrustadas (*** NOT A PHYSICAL ITEM ***), desbordamiento de columnas CSV.\n4. Duplicación: descripciones cortas/largas idénticas; texto boilerplate compartido por 20+ SKU; clusters de longitud exacta (254/255/500 caracteres) que indican límites VARCHAR upstream.\n5. Verificación de realidad del enriquecimiento: para cada campo ML/enriquecido/embedding que el esquema promete, su cobertura real.\n\nNúmeros, 5 ejemplos textuales cada uno, severidad, y qué problemas necesitan un pase de enriquecimiento con LLM vs. una corrección del pipeline vs. una corrección de la capa de sinónimos.La mitad del tráfico de búsqueda B2B es alguien escribiendo un número de parte. La coincidencia exacta es todo el juego ahí, y falla de maneras silenciosas.
\nEn un catálogo, el número de parte indexado era un SKU numérico interno en el 99,99 % de los registros. El número del fabricante —el que está impreso en la caja— existía solo dentro de descripciones de texto libre. 183 000 productos inalcanzables por el número que un cliente realmente escribiría.
\nOtro catálogo tenía un sistema de expansión de variantes: quita los guiones, colapsa los segmentos, indexa las variantes para que la búsqueda por número de parte permisiva funcione. Buena idea. Pero el generador era combinatorio (hasta 80 variantes por producto), y en 11 826 registros una variante generada de un producto equivalía exactamente al número de parte canónico de un producto diferente. Las fijaciones son el caso brutal, porque la puntuación codifica dimensiones físicas: 702-1-5/32 es una pieza de 1-5/32 pulgadas y 702-15/32 es una pieza de 15/32 pulgadas, y ambas normalizan a 7021532. Un cliente escribe un número de parte exacto y obtiene un volado entre la pieza correcta y su prima dimensional.
También en esta categoría: referencias cruzadas de competidores ("Tengo el número de Ferguson, ¿cuál es el tuyo?") almacenadas como blobs delimitados por tubería sin dividir como 19MU82|Fastenal 0269214|Ferguson M48222407, en campos configurados como no buscables, así que un movimiento central de venta B2B simplemente no funciona. Y bifurcaciones de espacios en blanco —el mismo número de parte indexado tres veces (plano, rellenado con NBSP, espacio final)— más gemelos mojibake de UTF-8 decodificado dos veces.
El principio que arregla la mayor parte de esto: lo exacto debe vencer a lo difuso estructuralmente, no probabilísticamente. Una cláusula exacta que preserve la puntuación puntuada estrictamente por encima de cualquier nivel normalizado, nunca una coincidencia plana donde una variante pueda empatar con un acierto canónico. Verifica las variantes generadas contra el espacio de números de parte canónicos antes de indexar y descarta las colisiones. Normaliza Unicode antes de derivar IDs de registro. Divide los blobs de referencias cruzadas en arrays; esa es una sola línea de código de ingesta que desbloquea toda una clase de consultas.
\nMismo volcado. Mis usuarios buscan por número de parte; audita la integridad de coincidencia exacta:\n\n1. Qué campos tipo PN existen (part_number, mpn, PN alternativos/de competidor/del cliente, UPC), su cobertura, y cuáles están configurados como no buscables mientras contienen datos reales.\n2. Registros cuyo único token de PN buscable es un SKU interno (el número de parte real del fabricante aparece solo dentro del texto de descripción —muestra el patrón).\n3. Si hay un campo de expansión de variantes/keywords de PN: encuentra cada variante generada que iguale el PN canónico de un registro DIFERENTE (normaliza: minúsculas, quita puntuación). Muestra pares colisionantes —especialmente tamaños de fijaciones que llevan fracciones.\n4. PN que difieren solo por espacios en blanco/caracteres invisibles/mayúsculas/minúsculas del PN de otro registro (bifurcaciones de identidad duplicada).\n5. Campos de referencias cruzadas multivalor almacenados como blobs delimitados en lugar de arrays.\n\nConteos, ejemplos, y para cada problema la regla de ingesta o cambio en el constructor de consultas que lo arregla.Algunas cosas que no encajaron arriba pero merecen una oración: un generador de sinónimos que convertía cualquier número en términos de calibre de alambre, así que REF#259286 se convirtió en "259286 awg" y una rosca de tornillo #8-32 se convirtió en "8 gauge wire" (miles de registros ahora coinciden con consultas eléctricas con las que no tienen nada que ver); banderas internas de una plataforma de comercio electrónico indexadas como especificaciones de producto buscables, 2,1 millones de pares clave-valor basura; y 18 campos de esquema poblados en cero registros en ninguna parte. Los generadores de expansión necesitan compuertas de contexto. El esquema muerto es una falsa promesa sobre la que alguien eventualmente construirá.
En mi auditoría, los campos de categoría faltaban en el 83 % de un catálogo. Las claves de atributo no tenían taxonomía alguna —7 068 claves de especificación distintas en un catálogo de 156K registros, el 64 % de ellas usadas en menos de diez productos, con deriva como horse_power vs horsepower dividiendo el mismo atributo entre facetas. Y el detalle al que vuelvo una y otra vez: dos de los cuatro catálogos tenían campos UNSPSC sentados en sus esquemas, mapeados y listos, poblados en exactamente cero registros. Alguien sabía que la categorización importaba, construyó el hueco y nunca lo llenó. Apostaría dinero a por qué: clasificar 300K SKU en una taxonomía a mano es un año de trabajo del equipo de catálogo, así que se quedó en el roadmap para siempre.
Si estás fuera del B2B, UNSPSC es el Código de Productos y Servicios Estándar de la ONU, la taxonomía que hablan los sistemas de compras. Esta es la parte que la búsqueda de consumo no tiene: los sistemas de compras de tus clientes lo requieren. Los catálogos punchout, las plataformas de e-procurement y las herramientas de análisis de gasto están construidos alrededor de los códigos UNSPSC. Un distribuidor cuyo catálogo lleve códigos limpios puede conectarse al sistema de compras de un contratista o un hospital. Uno sin ellos es una lista de precios en PDF con una caja de búsqueda. Internamente, también es lo que potencia las facetas de categoría, el ranking por categoría ("un número que se parsea como calibre de alambre solo debería boostear alambre"), la deduplicación entre catálogos, y las compuertas de contexto para cada generador de expansión en la Categoría 4.
\nY ahora es un trabajo por lotes. Esta es la misma forma de problema que DoorDash describe resolver con LLM —etiquetado de alto volumen contra un vocabulario controlado— y el enfoque se transfiere directamente:
\nEl costo es casi vergonzoso de escribir. La clasificación es una tarea de salida corta: aproximadamente 300 tokens de entrada por registro y 30 de salida. En Claude Haiku 4.5 con precios de Batch API, eso es unos 17 centavos por mil SKU. Toda mi flota de 775K registros se clasificaría por unos $130. Lo que estuvo en el roadmap durante años porque era un año de trabajo manual cuesta menos que el almuerzo del equipo donde lo discutirías.
\nClasificas productos de distribuidores B2B en UNSPSC. Adjunto: la lista de familias UNSPSC (nivel 2, ~450 entradas) como datos de referencia.\n\nPara cada registro de producto (título, descripción, marca, número de parte, cualquier texto de categoría existente), emite JSON:\n- unspsc_family: el código de familia de 4 dígitos —elige SOLO de la lista adjunta\n- family_confidence: high | low\n- rationale: una frase corta (p. ej. "copper press fitting -> pipe fittings")\n\nReglas: juzga por la función del producto, no por su marca. Taquigrafía del oficio: CXC/FPT/MPT son conexiones de tubería, ELL es codo, CPLG es acoplamiento, una fracción+material desnuda suele ser un tamaño de accesorio. Si el registro no es un producto físico (líneas de flete, cargos adicionales, "*** NOT A PHYSICAL ITEM ***"), emite NOT_A_PRODUCT. Usa low confidence libremente —los registros de baja confianza reciben un segundo pase con la lista a nivel de clase.El pipeline de corrección tiene tres niveles más el trabajo de clasificación. El truco es gastar en el nivel correcto, porque casi nunca necesitas una llamada a LLM por registro.
\nflowchart LR\n A["Nivel 0 - Reglas<br/>código determinista<br/>~$0"] --> B["Nivel 1 - LLM sobre valores únicos<br/>marcas · claves de espec · unidades<br/>decenas de dólares"]\n B --> C["Nivel 2 - LLM por registro<br/>títulos · atributos · UNSPSC<br/>cientos de dólares"]\n C --> G["Compuertas de ingesta<br/>cada corrección se convierte en un validador"]\n
El Nivel 0 es código determinista y básicamente es gratis. Quita HTML y decodifica entidades. Convierte centinelas en nulos reales con banderas explícitas. Repara UPC (relleno izquierdo, rechaza notación científica, valida el dígito de verificación). Normaliza Unicode en IDs. Divide las referencias cruzadas delimitadas por tubería. Descarta variantes de PN que colisionen con el número canónico de otro producto. Elimina esquemas muertos. Un agente escribe estos scripts en una sesión, y este nivel arregló aproximadamente la mitad de todo lo que encontró mi auditoría. Hazlo antes de cualquier enriquecimiento, o pagarás a un modelo para que reescriba bellamente títulos de productos que tu pipeline descartó silenciosamente.
\nEl Nivel 1 ejecuta el LLM sobre valores únicos, no sobre registros. Este es el truco que hace que los problemas de vocabulario sean baratos: mi peor catálogo tenía 313K registros pero solo 741 cadenas de marca distintas. La normalización de marcas es un trabajo sobre 741 cadenas —agrupa las variantes de mayúsculas/minúsculas, mapea submarcas a padres, marca los marcadores de posición— no 313K llamadas. El mismo movimiento para claves de especificación y sufijos de unidad. Cada trabajo de vocabulario cuesta un dígito de dólares y su salida es una tabla de alias estática que tu ingesta aplica para siempre, de forma determinista. Llama a todo el nivel $20-50 para una flota, gastado principalmente en pases de revisión.
\nAdjunto: la distribución completa de valores distintos de mis campos de marca y fabricante (value, record_count). Produce una tabla de normalización:\n\ncanonical_brand, parent_manufacturer, [raw variants], confidence\n\nReglas: agrupa variantes de mayúsculas/minúsculas/puntuación/espacios en blanco; mapea submarcas a fabricantes padres como una columna separada (no las fusiones); marca valores de marcador de posición como NULL_SENTINEL; marca líneas de producto o categorías mal archivadas como marcas como NOT_A_BRAND. Marca clusters inciertos en lugar de adivinar. Emite CSV, luego escribe un script que lo aplique en la ingesta y registre valores nuevos no emparejados.El Nivel 2 es el pase por registro: un título legible para el cliente, expansiones de búsqueda, atributos estructurados y un número de parte del fabricante recuperado para cada producto. Por SKU es pequeño —alrededor de 400 tokens de entrada (el registro, más instrucciones compartidas que el cacheo de prompts hace casi gratis) y 250 de salida. Dos palancas antes de siquiera elegir un modelo: enriquece lo que está activo (en mi peor catálogo solo el 14 % de los registros estaban activos, un recorte del 86 % ahí mismo), y usa una API de batch donde el proveedor la tenga, ya que el enriquecimiento no tiene requisito de latencia y tanto Anthropic como OpenAI rebajan un 50 % por batch.
\nCoticé el mismo trabajo en todo lo que plausiblemente usarías en 2026 —Claude, los tres niveles de GPT-5.6 (Sol, Terra, Luna), Kimi K3, GLM-5.2, Qwen3.5 y DeepSeek V4. Misma carga de trabajo, tarifas publicadas por los proveedores, descuento por batch aplicado donde existe:
\n![\"Cost](\"/assets/images/b2b-search-enrichment-cost-by-model.png\")
\nTuve que verificar dos veces estos números porque parecían incorrectos. La versión peor caso de este proyecto —un modelo frontera, cada SKU, sin filtrado alguno— llega a unos $3 800. El piso está por debajo de los cien dólares: DeepSeek V4-Flash enriquecería toda la flota por el precio de un taladro decente. La versión que realmente ejecutarías mezcla niveles: un modelo económico (Haiku, Luna, Qwen Flash, DeepSeek) para la mayoría mecánica, un modelo de gama media (Sonnet, Terra, GLM-5.2) para la cola de ensalada de abreviaturas que el pequeño marca como baja confianza, y un modelo frontera haciendo spot-check a una muestra del 1-2 % como compuerta de calidad. Eso aterriza en unos pocos cientos de dólares para los SKU activos sin importar qué proveedores elijas.
\nDos advertencias que el gráfico no puede mostrar. Los modelos baratos solo son baratos si su salida sobrevive tu evaluación —ejecuta la comparación de 200 muestras antes de comprometerte, porque un modelo económico que estropee el 5 % de los números de parte cuesta más que el modelo frontera que no lo hace. Y tu catálogo es dato competitivo: precios, referencias cruzadas y números de parte del cliente están en esos registros, así que verifica los términos de retención de datos y entrenamiento de cada proveedor antes de enviar 775K registros al endpoint más barato de la lista. Para muchos distribuidores, esa sola verificación incluye o excluye a algunos proveedores, y las opciones de peso abierto (DeepSeek, GLM, Qwen, Kimi) tienen la propiedad extra de que puedes autoalojarlas si los datos no pueden salir en absoluto.
\nSuma el pase UNSPSC de ~$130 (que escala de la misma manera entre modelos —en el nivel económico baja a calderilla) y el trabajo de vocabulario, y toda la transformación del catálogo cuesta en algún lugar entre unos pocos cientos y unos pocos miles de dólares, frente a un trabajo que solía ser un año del equipo de merchandising. Es la misma economía de lotes offline que describe Instacart, solo que a escala de catálogo comercial donde los números se vuelven lo suficientemente pequeños para ponerlos en una tarjeta de crédito.
\nCómo se ve en un registro real de mi auditoría:
\nIN: part_number: 1678619\n short_desc: PROPRESS 2-1/2X1 CXC RED CPLG 20685\n brand: (placeholder)\n\nOUT: display_title: 2-1/2" x 1" ProPress Copper Reducing Coupling\n search_expansions: ["copper press fitting", "reducing coupling",\n "press x press coupling"]\n attributes: {size_1: {value: 2.5, unit: in},\n size_2: {value: 1, unit: in},\n material: copper, connection: press}\n extracted_mpn: "20685"\n unspsc_family: 4017 (pipe fittings)\n confidence: highMira la línea extracted_mpn. El mismo pase recupera números de parte del fabricante que antes estaban enterrados en el texto de descripción —en uno de mis catálogos, eso son 183K productos volviéndose encontrables por el número impreso en la caja. Eso solo paga el trabajo por lotes.
Enriqueces registros de productos de distribuidores B2B para búsqueda. Para cada registro de entrada (nombre crudo del ERP, descripciones, marca, número de parte, categoría) produce JSON:\n\n- display_title: legible para el cliente, <=80 caracteres, Title Case. Expande abreviaturas del oficio (CXC -> copper x copper connection, ELL -> elbow, CPLG -> coupling, RED -> reducing). Mantén cada número de parte, código de modelo y dimensión VERBATIM tal como se escribió —nunca deletrees códigos en palabras.\n- search_expansions: 2-5 frases que un cliente podría escribir y que no aparecen en el texto crudo (tipo de producto en inglés llano, nombres comunes del oficio). Nunca inventes especificaciones ausentes en la fuente.\n- attributes: {name: {value, unit}} extraídos SOLO del texto fuente.\n- extracted_mpn: número de parte del fabricante si está presente en el texto de descripción (usualmente el token después de la marca) y ausente en los campos de PN, si no null.\n- confidence: high | low. Usa low siempre que tengas que adivinar; una respuesta low enrutada a revisión vence a una alucinación confiada.Dos notas de producción: pon las instrucciones compartidas en un prefijo de prompt cacheado (el cacheo reduce el lado de entrada hasta un 90 % además del descuento por batch), y usa salidas estructuradas con un esquema JSON para que nunca pagues un impuesto por fallo de parseo.
\nEl último nivel es el que la gente se salta, y es el que se capitaliza. La auditoría vale por una limpieza. Los validadores que genera valen por cada feed futuro. Termina la sesión de corrección con:
\nConvierte cada problema que acabamos de arreglar en una verificación automatizada que haga fallar ruidosamente el pipeline de ingesta: aserciones de cobertura de campos derivados, listas de bloqueo de centinelas, aserciones de tipo en campos de texto, validación de checksum de identificadores, verificaciones de colisión de variantes de PN, reglas de higiene de id, seguimiento de cobertura UNSPSC, y una alarma de frescura de datos por catálogo. Emítelos como tests que CI ejecute contra una muestra de cada nuevo feed.Omit esto y las mismas exportaciones de ERP regenerarán la misma basura en un trimestre, y pagarás la limpieza dos veces. Lo sé porque dos de los bugs que encontró mi auditoría claramente se habían arreglado antes, y habían vuelto.
\nUn paso de configuración: vuelca tu catálogo a JSONL, un objeto JSON por línea con un id único y los campos del registro. Sea cual sea tu plataforma —Elasticsearch, OpenSearch, Solr, Algolia, Typesense, un PIM, la base de datos detrás de todo— solo pídele al agente que escriba el exportador:
Escribe un script que exporte cada registro de producto de mi catálogo [describe: nombre del índice de búsqueda / tabla de base de datos / exportación de PIM] a ./dump/records-{n}.jsonl en fragmentos de 50k registros —un objeto JSON por línea con un "id" único más todos los campos— y mi definición de campo/esquema (si la plataforma tiene una) a schema.json. Verifica que el conteo exportado coincida con el conteo fuente.Con Claude Code, suelta cualquier prompt de categoría en una sesión en ese directorio. Escribe y ejecuta el análisis él mismo, pases completos sin excusas de muestreo, y vuelve con recibos a nivel de registro. Cuando dices "ahora arréglalo", la misma sesión produce el validador de ingesta, el script de backfill y el trabajo de enriquecimiento por lotes. Ejecuta las categorías como sesiones paralelas o subagentes; así ejecuté las mías, y toda la auditoría tomó unos doce minutos de tiempo de reloj. Con Codex, codex exec maneja los pases de análisis de solo lectura usando los mismos prompts; mantén las correcciones del lado de escritura en una sesión que revises.
Tres reglas que aprendí a la mala:
\nAmazon, DoorDash e Instacart no publicaron su trabajo de catálogo-LLM como caridad. Lo publicaron porque las técnicas son generales y la ventaja competitiva es la ejecución. Y las técnicas se transfieren a la distribución comercial mejor que casi en cualquier otro lugar que se me ocurra: los catálogos son lo suficientemente pequeños para que un pase completo sea barato, los datos son lo suficientemente malos como para que el margen de mejora sea enorme, las consultas llevan dinero real, y el mundo de las compras ya funciona sobre una taxonomía que un trabajo por lotes ahora puede poblar por unos $130.
\nDe las docenas de problemas que mi auditoría sacó a la luz en cuatro catálogos de distribuidores, ni uno solo era visible desde la capa de ranking. Todos la degradaban. La cadena de suministro que alimenta esos índices —las exportaciones de ERP, las hojas de cálculo de proveedores, los antiguos parsers de CSV— es exactamente lo que el manual publicado arregla. Los distribuidores que lo ejecuten tendrán búsqueda de nivel marketplace en catálogos donde sus competidores todavía no pueden encontrar una bobina de condensador.
\nLa pregunta "¿hay algo mal con mis datos?" solía costar dos semanas del tiempo de alguien, por eso nadie la hacía. Ahora cuesta un prompt. Hazla.
", "source_hash": "sha256:beacaae673c45f36f13a5677632c8df46a2339c6bdea51c65c49f762d7f0805c", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T07:39:21.935368+00:00" }