Cum am folosit AI pentru a remedia valorile de atribute inconsistente la scară în comerțul electronic

Când oamenii vorbesc despre scalarea comerțului electronic, se concentrează pe provocările de inginerie majore: căutare distribuită, inventar în timp real, motoare de recomandare și optimizarea procesului de finalizare a comenzii. Dar sub toate acestea se află o problemă mai liniștită, mai persistentă, cu care aproape fiecare comerciant se confruntă: valorile atributelor.

Atributele sunt coloana vertebrală a descoperirii produselor. Ele alimentează filtrele, comparațiile, clasificarea căutărilor și logica de recomandare. Dar în cataloagele reale, valorile atributelor sunt rareori curate. Sunt inconsistente, duplicate, formatate greșit sau ambigue semantic.

Luați ceva simplu precum Dimensiune. Ați putea vedea:

Cod

["XL", "Small", "12cm", "Large", "M", "S"]

Sau Culoare:

Cod

["RAL 3020", "Crimson", "Red", "Dark Red"]

Individual, aceste inconsistențe par inofensive. Dar înmulțiți-le pe peste 3 milioane de SKU-uri, fiecare cu zeci de atribute, și problema devine sistemică. Filtrele se comportă imprevizibil, motoarele de căutare pierd relevanța, comercianții se înec în curățarea manuală, iar descoperirea produselor devine mai lentă și mai frustrantă pentru clienți.

Aceasta a fost provocarea cu care m-am confruntat ca inginer software full-stack la Zoro, o problemă ușor de trecut cu vederea, dar care afecta fiecare pagină de produs.

Abordarea mea: AI Hibrid întâlnește Determinismul

Nu doream un AI misterios de tip cutie neagră care pur și simplu sortează lucrurile. Sistemele de genul acesta sunt greu de avut încredere, de depanat sau de scalat. În schimb, am urmărit o conductă care să fie:

• explicabilă
• previzibilă
• scalabilă
• controlabilă de oameni

Rezultatul a fost o conductă AI hibridă care combină raționamentul contextual din LLM-uri cu reguli clare și controale pentru comercianți. Acționează inteligent când este necesar, dar rămâne întotdeauna previzibilă. Acesta este AI cu balustrade de protecție, nu AI scăpat de sub control.

Taskuri în fundal: Construite pentru randament

Toată procesarea atributelor se întâmplă în taskuri de fundal offline, nu în timp real. Aceasta nu a fost un compromis; a fost o alegere arhitecturală strategică.

Conductele în timp real sună atrăgător, dar la scară de comerț electronic, ele introduc:

• latență imprevizibilă
• dependențe fragile
• vârfuri costisitoare de calcul
• fragilitate operațională

Taskurile offline, pe de altă parte, ne-au oferit:

• Randament ridicat: loturi uriașe procesate fără a afecta sistemele live
• Reziliență: eșecurile nu au afectat niciodată traficul clienților
• Control al costurilor: calculul putea fi programat în perioadele cu trafic redus
• Izolare: latența LLM nu a afectat niciodată paginile de produse
• Consistență: actualizările erau atomice și previzibile

Menținerea sistemelor orientate către clienți separate de conductele de procesare a datelor este esențială atunci când lucrați cu milioane de SKU-uri.

Curățare & Normalizare

Înainte de a folosi AI pe date, am rulat un pas clar de preprocesare pentru a elimina zgomotul și confuzia. Acest pas poate părea simplu, dar a îmbunătățit considerabil raționamentul LLM-ului.

Conducta de curățare a inclus:

• eliminarea spațiilor albe
• eliminarea valorilor goale
• deduplicarea valorilor
• aplatizarea breadcrumb-urilor de categorie într-un șir contextual

Acest lucru a asigurat că LLM-ul primea input curat și clar, ceea ce este esențial pentru rezultate consistente. Gunoi la intrare, gunoi la ieșire. La această scară, chiar și erorile mici pot duce la probleme mai mari mai târziu.

Serviciu LLM cu context

LLM-ul nu doar sortea valorile alfabetic. Raționează despre ele.

Serviciul primea:

• valori de atribute curățate
• breadcrumb-uri de categorie
• metadate de atribute

Cu acest context, modelul putea înțelege:

• Că "Voltage" în Scule electrice este numeric
• că "Size" în Îmbrăcăminte urmează o progresie cunoscută
• că "Colour" în Vopsele ar putea urma standardele RAL
• că "Material" în Hardware are relații semantice

Modelul returna:

• valori ordonate
• nume de atribute rafinate
• o decizie: ordonare deterministă sau contextuală

Acest lucru permite conductei să gestioneze diferite tipuri de atribute fără a codifica reguli pentru fiecare categorie.

Fallback-uri deterministe

Nu fiecare atribut necesită AI.

De fapt, multe atribute sunt gestionate mai bine prin logică deterministă.

Intervalele numerice, valorile bazate pe unități și seturile simple beneficiază adesea de:

• procesare mai rapidă
• ordonare previzibilă
• cost mai mic
• zero ambiguitate

Conducta detecta automat aceste cazuri și folosea logica deterministă pentru ele. Acest lucru a menținut sistemul eficient și a evitat apelurile LLM inutile.

Etichetare manuală vs LLM

Comercianții aveau încă nevoie de control, în special pentru atributele sensibile din punct de vedere comercial.

Astfel, fiecare categorie putea fi etichetată ca:

• LLM_SORT — lasă modelul să decidă
• MANUAL_SORT — comercianții definesc ordinea

Acest sistem cu două etichete permite oamenilor să ia deciziile finale în timp ce AI făcea cea mai mare parte a muncii. De asemenea, a construit încredere, deoarece comercianții puteau suprascrie modelul când era necesar fără a strica conducta.

Persistență & control

Toate rezultatele au fost stocate direct într-o bază de date Product MongoDB, menținând arhitectura simplă și centralizată.

MongoDB a devenit singurul depozit operațional pentru:

• valori de atribute sortate
• nume de atribute rafinate
• etichete de sortare la nivel de categorie
• câmpuri sortOrder la nivel de produs

Acest lucru a făcut ușoară revizuirea modificărilor, suprascrierea valorilor, reprocesarea categoriilor și sincronizarea cu alte sisteme.

Integrare cu căutarea

Odată sortate, valorile au fost transmise către:

• Elasticsearch pentru căutare bazată pe cuvinte cheie
• Vespa pentru căutare semantică și bazată pe vectori

Acest lucru a asigurat că:

• filtrele apar în ordine logică
• Paginile de produse afișau atribute consistente
• motoarele de căutare clasificau produsele mai precis
• Clienții puteau naviga categoriile mai ușor

Căutarea este locul unde sortarea atributelor este cel mai vizibilă și unde consistența contează cel mai mult.

Prezentare generală a arhitecturii

Pentru a face acest lucru să funcționeze pe milioane de SKU-uri, am proiectat o conductă modulară construită în jurul taskurilor de fundal, raționamentului AI și integrării căutării. Diagrama de arhitectură de mai jos surprinde fluxul complet:

• Datele produsului intră din Sistemul de informații despre produse
• Taskul de extragere a atributelor extrage valorile atributelor și contextul categoriei
• Acestea sunt transmise către Serviciul de sortare AI
• Documentele de produs actualizate sunt scrise în Product MongoDB
• Taskul Outbound Sync actualizează Sistemul de informații despre produse cu ordinea de sortare
• Taskurile Elasticsearch și Vespa Sync împing datele sortate în sistemele lor respective de căutare
• Serviciile API conectează Elasticsearch și Vespa la aplicația client

Acest flux asigură că fiecare valoare de atribut, fie sortată de AI sau setată manual, se reflectă în căutare, merchandising și experiența clientului.

Soluția în acțiune

Iată cum au fost transformate valorile dezordonate:

| Atribut | Valori brute | Output ordonat | |----|----|----| | Size | XL, Small, 12cm, Large, M, S | Small, M, Large, XL, 12cm | | Color | RAL 3020, Crimson, Red, Dark Red | Red, Dark Red, Crimson, Red (RAL 3020) | | Material | Steel, Carbon Steel, Stainless, Stainless Steel | Steel, Stainless Steel, Carbon Steel | | Numeric | 5cm, 12cm, 2cm, 20cm | 2cm, 5cm, 12cm, 20cm |

Aceste exemple arată cum conducta combină raționamentul contextual cu reguli clare pentru a crea secvențe curate, ușor de înțeles.

De ce taskuri offline în loc de procesare în timp real?

Procesarea în timp real ar fi introdus:

• latență imprevizibilă
• Costuri de calcul mai ridicate
• dependențe fragile
• complexitate operațională

Taskurile offline ne-au oferit:

• eficiență în loturi
• apeluri LLM asincrone
• logică de reîncercare și cozi de erori
• ferestre de revizuire umană
• cheltuieli de calcul previzibile

Compromisul a fost o mică întârziere între ingestia datelor și afișare, dar beneficiul a fost consistența la scară, pe care clienții o apreciază mult mai mult.

Impact

Rezultatele au fost semnificative:

• Ordonare consistentă a atributelor pe peste 3M+ SKU-uri
• Sortare numerică previzibilă prin fallback-uri deterministe
• Control al comercianților prin etichetare manuală
• Pagini de produse mai curate și filtre mai intuitive
• Relevanță îmbunătățită a căutării
• Încredere și conversie mai mari ale clienților

Aceasta nu a fost doar o victorie tehnică; a fost și o victorie pentru experiența utilizatorului și venituri.

Lecții învățate

• Conductele hibride depășesc AI-ul pur la scară. Balustradele de protecție sunt importante.
• Contextul îmbunătățește dramatic acuratețea LLM
• Taskurile offline sunt esențiale pentru randament și reziliență
• Mecanismele de suprascriere umană construiesc încredere și adoptare
• Input-ul curat este fundația output-ului AI fiabil

Gând final

Sortarea valorilor atributelor sună simplu, dar devine o provocare reală când trebuie să o faci pentru milioane de produse.

Combinând inteligența LLM cu reguli clare și controlul comercianților, am transformat o problemă complexă și ascunsă într-un sistem curat și scalabil.

Este o reamintire că unele dintre cele mai mari victorii provin din rezolvarea problemelor plictisitoare, cele care sunt ușor de ratat, dar apar pe fiecare pagină de produs.

\n \n \n