{ "title": "AI के युग में B2B कॉमर्स सर्च को ठीक करना", "excerpt": "मैंने चार B2B वितरकों के लिए सर्च को पावर देने वाले 775,000 उत्पाद रिकॉर्ड का ऑडिट किया। उपभोक्ता दिग्गजों ने पहले ही प्रकाशित कर दिया है कि LLM के साथ ऐसे कैटलॉग को कैसे ठीक किया जाए, लेकिन ट्रेड डिस्ट्रीब्यूशन ने प्लेबुक नहीं उठाया है। यह रहा, HVAC, प्लंबिंग और इलेक्ट्रिकल के लिए अनुकूलित, वास्तविक लागत के साथ।", "content_html": "

B2B कॉमर्स सर्च में एक गंदा रहस्य है: रैंकिंग एल्गोरिदम शायद ही कभी समस्या होती है।

\n

जब परिणाम खराब होते हैं, तो टीमें मज़ेदार लीवर तक पहुंचती हैं। बूस्ट, समानार्थक शब्द, एम्बेडिंग, रीरैंकर, और हाल ही में LLM क्वेरी समझ। मैंने खुद वे सभी लीवर खींचे हैं। पिछले हफ्ते मैंने इसके बजाय अनग्लैमरस काम किया: मैंने चार प्रोडक्शन सर्च इंडेक्स से हर उत्पाद रिकॉर्ड डंप किया - HVAC, प्लंबिंग, औद्योगिक आपूर्ति और फास्टनरों में चार B2B वितरकों में 775,051 रिकॉर्ड - और डेटा का ही ऑडिट किया। मैंने समानांतर में चलने वाले बारह AI एजेंटों का उपयोग किया, प्रत्येक को एक आयाम सौंपा गया: कवरेज, टेक्स्ट गुणवत्ता, पार्ट नंबर, ब्रांड, मूल्य निर्धारण, स्पेक्स, श्रेणियां, मीडिया, डुप्लिकेट।

\n

जो वापस आया वह किसी ऐसे व्यक्ति के लिए साधारण होता जिसने वितरक के कैटलॉग पर काम किया है, और जिसने नहीं किया है उसके लिए चौंकाने वाला। लेकिन जो हिस्सा मेरे साथ अटका हुआ है वह यह है: समाधान पहले से ही प्रकाशित है। Amazon, DoorDash और Instacart ने दो साल बिताए हैं, सार्वजनिक इंजीनियरिंग ब्लॉगों में, यह लिखने में कि वे बड़े पैमाने पर गंदे कैटलॉग को साफ करने, लेबल करने और समृद्ध करने के लिए LLM का उपयोग कैसे करते हैं। ट्रेड डिस्ट्रीब्यूशन ने ज्यादातर ध्यान नहीं दिया है। जो अजीब है, क्योंकि इसके कैटलॉग गंदे हैं, इसकी क्वेरी अधिक मूल्यवान हैं (एक ठेकेदार $4,000 कंडेनसर का ऑर्डर कर रहा है, $12 दोपहर का भोजन नहीं), और इसके कैटलॉग आकार वास्तव में अर्थशास्त्र को आसान बनाते हैं।

\n

तो यह पोस्ट वह प्लेबुक है, जो ट्रेड डिस्ट्रीब्यूशन के लिए अनुकूलित है: डेटा समस्याएं जो B2B सर्च को तोड़ती हैं, उन्हें आज दोपहर एक कोडिंग एजेंट के साथ कैसे खोजें, LLM के साथ उन्हें कैसे ठीक करें जिसमें UNSPSC वर्गीकरण शामिल है, और पूरी चीज़ की लागत क्या है। आखिरी पर स्पॉइलर: आपके अनुमान से दो ऑर्डर ऑफ मैग्नीट्यूड कम।

\n

प्लेबुक पहले से मौजूद है, बस हमारे उद्योग में नहीं

\n

मार्केटप्लेस कंपनियों ने जो कुछ प्रकाशित किया है:

\n\n

सामान्य सूत्र को याद करना आसान है: LLM जीत कैटलॉग-पक्ष और ऑफ़लाइन हैं। ये कंपनियां एक भी क्वेरी आने से पहले डेटा को समृद्ध करती हैं। डिस्कवरी सिस्टम एक ऑफ़लाइन पक्ष में विभाजित होते हैं जो आर्टिफैक्ट बनाता है (कैटलॉग, इंडेक्स, एम्बेडिंग) और एक ऑनलाइन पक्ष जो उन पर पुनर्प्राप्त और रैंक करता है, और लगभग सभी प्रकाशित LLM मूल्य ऑफ़लाइन उतरता है। रैंकिंग परत केवल उतनी ही अच्छी हो सकती है जितनी उसे खिलाई जाती है।

\n

अब एक विशिष्ट HVAC या प्लंबिंग वितरक के कैटलॉग की कल्पना करें। यह ERP निर्यात, आपूर्तिकर्ता स्प्रेडशीट, खरीद समूह फ़ीड और एक CSV पार्सर से जुड़ा हुआ है जो किसी ने एक दशक पहले लिखा था। उत्पाद "शीर्षक" गोदाम पिकर्स के लिए लिखे गए चालान आशुलिपि हैं। और इस पर हिट होने वाला सर्च ट्रैफ़िक उतना ही इरादा-घना है जितना सर्च ट्रैफ़िक मिलता है: आधा सटीक पार्ट नंबर, बाकी व्यापार शब्दजाल जैसे "3/4 cxc 90 ell।" ईमानदारी से, मैं इस प्लेबुक के लिए बेहतर वातावरण नहीं सोच सकता। क्वेरी मूल्यवान हैं, डेटा ठीक करने योग्य है, और कुछ सौ हज़ार SKU पर, कैटलॉग पर एक पूर्ण LLM पास की लागत सैकड़ों डॉलर है। लाखों नहीं। सैकड़ों।

\n

यहाँ ऑडिट का आकार है, क्योंकि आप इसे पुन: पेश करना चाहेंगे:

\n
flowchart TD\n    D[\"Raw catalog dump
(JSONL, one record per line)\"] --> C1[\"Per-catalog coverage agents
null rates, distributions, dead fields\"]\n    D --> C2[\"Dimension agents
text · part numbers · brands · pricing
specs · categories · media · duplicates\"]\n    C1 --> S[\"Synthesis: findings ranked by
severity, with example records\"]\n    C2 --> S\n    S --> F[\"Fix pipeline: rules + LLM enrichment
+ UNSPSC classification + ingest gates\"]\n
\n

प्रॉम्प्ट से पहले प्रारूप पर एक नोट। नीचे सब कुछ एक सामान्य डंप पर काम करता है: प्रति पंक्ति एक JSON ऑब्जेक्ट, प्रत्येक में एक अद्वितीय id और रिकॉर्ड के फ़ील्ड। Elasticsearch, OpenSearch, Solr, Algolia, Typesense, एक PIM, एक सादा डेटाबेस निर्यात - कोई फर्क नहीं पड़ता। हर प्लेटफ़ॉर्म इस आकार का उत्पादन कर सकता है, और यहाँ हर प्रॉम्प्ट इसके खिलाफ चलता है।

\n

श्रेणी 1: मूक पाइपलाइन विफलताएं

\n

सबसे बुरी चीज़ जो मुझे मिली वह खराब डेटा नहीं था जो किसी ने लिखा था। यह डेटा था जिसे पाइपलाइन ने रास्ते में नष्ट कर दिया, बिना किसी को बताए।

\n

ये कैटलॉग इन्जेस्ट के समय अपना प्राथमिक सर्च टेक्स्ट बनाते हैं, एक स्क्रिप्टेड regex का उपयोग करके जो उत्पाद शीर्षकों से आयाम और इकाइयाँ निकालता है। लंबे शीर्षकों पर regex इंजन की जटिलता सीमा से आगे निकल जाता है, प्रोसेसर विफल हो जाता है, और रिकॉर्ड वैसे भी अनुक्रमित हो जाता है - एक त्रुटि फ़ील्ड के साथ जिसे कोई नहीं पढ़ता है और कोई प्राथमिक सर्च फ़ील्ड नहीं है।

\n

\"Documents

\n

पूरे बेड़े में, 52,570 रिकॉर्ड इंडेक्स में बैठे थे, मुख्य क्वेरी पथ के लिए अदृश्य। सबसे खराब कैटलॉग पर यह सात में से एक उत्पाद है। किसी डैशबोर्ड ने इसे नहीं पकड़ा क्योंकि कुछ भी विफल नहीं हुआ। पाइपलाइन ने पूरे दिन, हर दिन, महीनों तक सफलता लौटाई।

\n

उसी परिवार से दो और निष्कर्ष। स्थिर दर्पण: एक फ़ील्ड सत्य रखता है (प्रति-खाता एनटाइटलमेंट मैप), और एक दूसरा चपटा फ़ील्ड फ़िल्टरिंग के लिए इसे दर्पण करता है। एक कैटलॉग पर दर्पण 19.85% रिकॉर्ड पर बह गया था - 31,000 सक्रिय उत्पाद खाता-फ़िल्टर किए गए सर्च से गलत तरीके से छिपे हुए थे। और जमे हुए कैटलॉग: एक इंडेक्स दस सप्ताह में ताज़ा नहीं हुआ था जबकि इसके सहोदर दैनिक अपडेट होते थे। अपटाइम की निगरानी की गई थी। ताजगी नहीं।

\n

समाधान उबाऊ हैं और यही बात है। व्युत्पन्न-फ़ील्ड कवरेज पर अलर्ट करें (व्युत्पन्न फ़ील्ड खाली है जबकि इसका स्रोत नहीं है)। एक तथ्य के दो प्रतिनिधित्व न रखें; लेखन समय पर फ़िल्टर करने योग्य फ़ील्ड प्राप्त करें। प्रति कैटलॉग डेटा ताजगी देखें जैसे आप अपटाइम देखते हैं।

\n

यहाँ अपने स्वयं के कैटलॉग में यह सब खोजने के लिए प्रॉम्प्ट है (Claude Code या codex exec; अंत में यांत्रिकी):

\n
Here is a dump of my product catalog as JSONL files in ./dump/ - one JSON\nrecord per line, each with a unique \"id\" and the product fields. My field/\nschema definition (if any) is in schema.json.\n\nWrite streaming Python (don't load it all in memory) to find silent pipeline\nfailures:\n1. Records carrying any error/exception field a pipeline stamped on them.\n2. For every DERIVED field (concatenations, *_search, *_normalized variants):\n   records where the derived field is empty but its obvious source field\n   is not.\n3. Pairs of fields that look like mirrors of each other (one nested/rich,\n   one flat/filterable): quantify how often they disagree.\n4. The distribution of updated/indexed timestamps: is any slice of the\n   catalog frozen while the rest refreshes?\n\nReport each finding with counts, % of catalog, 5 example ids, and whether the\naffected records are active/visible. Rank by severity.\n
\n

श्रेणी 2: प्लेसहोल्डर और सेंटिनल, या: डेटा जो झूठ बोलता है

\n

शून्य जांच वह डेटा-गुणवत्ता उपकरण है जो सभी के पास पहले से है। प्लेसहोल्डर उन्हें हरा देते हैं, क्योंकि एक प्लेसहोल्डर आबाद है। यह सिर्फ सच नहीं है।

\n

मेरा पसंदीदा उदाहरण: एक 313K-SKU कैटलॉग पर, ब्रांड फ़ील्ड में 741 अलग-अलग मान और 99.99% आबादी थी। स्वस्थ लगता है। शीर्ष मान, सभी रिकॉर्ड के 88.8% पर, "Approved Vendor" था। एक ERP प्लेसहोल्डर। सबसे लोकप्रिय वास्तविक ब्रांड ने कैटलॉग का 0.3% कवर किया। इसलिए हर ब्रांड फ़ेसेट, ब्रांड बूस्ट और ब्रांड-जागरूक पुनर्लेखन कैटलॉग के नौ-दसवें हिस्से के लिए प्रभावी रूप से मृत था, जबकि फ़ेसेट UI खुशी से "Approved Vendor" को #1 ब्रांड फ़िल्टर के रूप में पेश करता था।

\n

एक बार जब आप देखना शुरू करते हैं, तो यह सामान हर जगह है:

\n\n

इस श्रेणी से मैंने जो सबक लिया: प्रति फ़ील्ड शीर्ष-एन मान वितरण का ऑडिट करें, शून्य दर नहीं। एक फ़ील्ड जो 100% आबाद है वह 88% कचरा हो सकता है, और कोई शून्य जांच आपको कभी नहीं बताएगी। फिर इन्जेस्ट पर सेंटिनल को ब्लैकलिस्ट करें, उन्हें स्पष्ट has_price / has_real_image फ़्लैग के साथ वास्तविक शून्य पर मैप करें, सीमा पर प्रकार-पुष्टि करें, और संरचनात्मक रूप से पहचानकर्ताओं को मान्य करें। किसी भी चीज़ को संदिग्ध मानें जो कभी स्प्रेडशीट से गुज़री हो।

\n
Same JSONL dump. For every field in my catalog, compute the top-20 value\ndistribution (full pass, streaming).\n\nFlag: (a) any single value covering >10% of records - placeholder/sentinel\ncandidates like \"Approved Vendor\", \"unknown\", 99999999, 0.0; (b) values whose\ntype differs from the field's dominant type (booleans in text fields, floats\namong strings); (c) identifier fields (UPC/EAN/GTIN/part numbers): validate\nchecksum and length, flag scientific notation, stripped leading zeros,\nembedded whitespace/unicode, and identifiers shared by multiple records;\n(d) category-like or product-line values sitting in brand fields.\n\nFor each flag: count, % of catalog, 5 verbatim examples with ids, and a\none-line proposed ingest rule that would have rejected it.\n
\n

श्रेणी 3: दरिद्र सामग्री

\n

वितरक कैटलॉग ERP द्वारा लिखे जाते हैं, मर्चेंडाइज़र द्वारा नहीं। टेक्स्ट चालान आशुलिपि है: PROPRESS 2-1/2X1 CXC RED CPLG, HC HX 18X8 W। एक कैटलॉग पर, एक तिहाई उत्पाद नामों में 60% से कम शब्दकोश शब्द थे। दूसरे पर, कच्चे नाम और विवरण फ़ील्ड 100% शून्य थे - टेक्स्ट केवल व्युत्पन्न सर्च ब्लॉब्स के अंदर मौजूद था, इसलिए जो कुछ भी कच्चे फ़ील्ड पढ़ता है (परिणाम शीर्षक, एम्बेडिंग इनपुट, प्रासंगिकता-न्यायाधीश प्रॉम्प्ट) कुछ भी नहीं पढ़ रहा था और कोई नहीं जानता था।

\n

\"Field

\n

वह हीटमैप ऑडिट से मेरा एकमात्र पसंदीदा आर्टिफैक्ट है। उन फ़ील्डों में से प्रत्येक हर स्कीमा में मौजूद है। संख्याएँ हैं कि वास्तव में प्रत्येक में कितना डेटा है। जो पंक्ति मुझे मिलती है वह एमएल-विवरण वाली है: स्कीमा ने हर रिकॉर्ड पर जिस संवर्धन परत का वादा किया था, वह 775,051 में से अठारह दस्तावेजों पर आबाद थी। अठारह। स्कोरिंग पाइपलाइन में हर "यदि संवर्धन मौजूद है तो उपयोग करें" शाखा एक मूक नो-ऑप थी। स्कीमा एक आकांक्षा है; केवल कवरेज एक तथ्य है।

\n

यह वह श्रेणी है जहाँ प्रकाशित प्लेबुक सबसे सीधे लागू होती है - DoorDash की विशेषता निष्कर्षण, Instacart की ऑफ़लाइन पीढ़ी - और लागत अनुभाग नीचे इसकी कीमत तय करता है। लेकिन एक पार्ट-नंबर व्यवसाय में चार नियम मायने रखते हैं, आंशिक रूप से पिछले संवर्धन प्रयास से सीखे गए जो गलत था:

\n\n
Same dump. Assess text quality of the customer-facing fields (name, short/long\ndescription) with a full streaming pass:\n\n1. Effective-title coverage: % of ACTIVE records with a non-empty display name.\n2. Readability: % ALL-CAPS names; % with under 60% dictionary-word tokens\n   (abbreviation salad); names under 10 chars; digits-only descriptions.\n3. Junk: HTML/CMS markup, encoding artifacts, embedded operational notes\n   (*** NOT A PHYSICAL ITEM ***), CSV column spillover.\n4. Duplication: identical short/long descriptions; boilerplate shared by 20+\n   SKUs; exact-length clusters (254/255/500 chars) indicating upstream\n   VARCHAR caps.\n5. Enrichment reality check: for every ML/enriched/embedding field the schema\n   promises, its actual coverage.\n\nNumbers, 5 verbatim examples each, severity, and which issues need an LLM\nenrichment pass vs. a pipeline fix vs. a synonym-layer fix.\n
\n

श्रेणी 4: पार्ट नंबर पवित्र हैं

\n

B2B सर्च ट्रैफ़िक का आधा हिस्सा कोई पार्ट नंबर टाइप कर रहा है। सटीक मिलान वहाँ पूरा खेल है, और यह शांत तरीकों से विफल रहता है।

\n

एक कैटलॉग पर, अनुक्रमित पार्ट नंबर 99.99% रिकॉर्ड पर एक आंतरिक संख्यात्मक SKU था। निर्माता का नंबर - जो बॉक्स पर मुद्रित होता है - केवल मुक्त-पाठ विवरणों के अंदर मौजूद था। 183,000 उत्पाद उस नंबर से अप्राप्य थे जो एक ग्राहक वास्तव में टाइप करेगा।

\n

एक अन्य कैटलॉग में एक संस्करण-विस्तार प्रणाली थी: डैश हटाएं, खंडों को संक्षिप्त करें, विविधताओं को अनुक्रमित करें ताकि क्षमाशील PN सर्च काम करे। अच्छा विचार। लेकिन जनरेटर कॉम्बिनेटरियल था (प्रति उत्पाद 80 विविधताओं तक), और 11,826 रिकॉर्ड पर एक उत्पाद की उत्पन्न विविधता बिल्कुल एक अलग उत्पाद के विहित पार्ट नंबर के बराबर थी। फास्टनर क्रूर मामला हैं, क्योंकि विराम चिह्न भौतिक आयामों को एन्कोड करता है: 702-1-5/32 एक 1-5/32 इंच का हिस्सा है और 702-15/32 एक 15/32 इंच का हिस्सा है, और दोनों 7021532 को सामान्य करते हैं। एक ग्राहक एक सटीक पार्ट नंबर टाइप करता है और सही हिस्से और उसके आयामी चचेरे भाई के बीच एक सिक्का उछाल प्राप्त करता है।

\n

इस श्रेणी में भी: प्रतियोगी क्रॉस-रेफरेंस ("मेरे पास फर्ग्यूसन नंबर है, तुम्हारा क्या है?") जो अविभाजित पाइप-सीमांकित ब्लॉब्स जैसे 19MU82|Fastenal 0269214|Ferguson M48222407 में संग्रहीत हैं, अनसर्चेबल के रूप में कॉन्फ़िगर किए गए फ़ील्ड में, इसलिए एक मुख्य B2B बिक्री गति काम नहीं करती है। और व्हाइटस्पेस फोर्क - एक ही पार्ट नंबर तीन बार अनुक्रमित (सादा, NBSP-पैडेड, अनुगामी-स्थान) - साथ ही डबल-डिकोडेड UTF-8 से mojibake जुड़वाँ।

\n

सिद्धांत जो इस अधिकांश को ठीक करता है: सटीक को संरचनात्मक रूप से फजी को हराना चाहिए, संभाव्य रूप से नहीं। एक विराम चिह्न-संरक्षण सटीक खंड किसी भी सामान्यीकृत स्तर से सख्ती से ऊपर स्कोर किया गया, कभी भी एक फ्लैट मैच नहीं जहां एक संस्करण एक विहित हिट को बांध सकता है। अनुक्रमण से पहले विहित PN स्थान के खिलाफ उत्पन्न विविधताओं की जांच करें और टकराव छोड़ दें। रिकॉर्ड आईडी प्राप्त करने से पहले यूनिकोड-सामान्य करें। क्रॉस-रेफरेंस ब्लॉब्स को सरणियों में विभाजित करें; वह एक इन्जेस्ट कोड की एक पंक्ति है जो एक पूरी क्वेरी क्लास को अनलॉक करती है।

\n
Same dump. My users search by part number; audit exact-match integrity:\n\n1. Which PN-ish fields exist (part_number, mpn, alt/competitor/customer PNs,\n   UPC), their coverage, and which are configured unsearchable while holding\n   real data.\n2. Records whose only searchable PN token is an internal SKU (real\n   manufacturer PN appears only inside description text - show the pattern).\n3. If there's a PN-variant/keyword expansion field: find every generated\n   variant that equals a DIFFERENT record's canonical PN (normalize:\n   lowercase, strip punctuation). Show colliding pairs - especially\n   fraction-bearing fastener sizes.\n4. PNs differing only by whitespace/invisible chars/case from another\n   record's PN (duplicate identity forks).\n5. Multi-value cross-reference fields stored as delimited blobs instead of\n   arrays.\n\nCounts, examples, and for each issue the ingest rule or query-builder change\nthat fixes it.\n
\n

कुछ चीजें जो ऊपर फिट नहीं हुईं लेकिन एक वाक्य की हकदार हैं: एक समानार्थी जनरेटर जिसने किसी भी संख्या को तार-गेज शब्दों में बदल दिया, इसलिए REF#259286 "259286 awg" बन गया और एक #8-32 स्क्रू थ्रेड "8 gauge wire" बन गया (हजारों रिकॉर्ड अब विद्युत प्रश्नों से मेल खाते हैं जिनसे उनका कोई लेना-देना नहीं है); एक ई-कॉमर्स प्लेटफ़ॉर्म के आंतरिक फ़्लैग खोजने योग्य उत्पाद स्पेक्स के रूप में अनुक्रमित, 2.1 मिलियन जंक कुंजी-मूल्य जोड़े; और 18 स्कीमा फ़ील्ड कहीं भी शून्य रिकॉर्ड पर आबाद हैं। विस्तार जनरेटर को संदर्भ गेट की आवश्यकता होती है। मृत स्कीमा एक झूठा वादा है जिस पर कोई अंततः निर्माण करेगा।

\n

लापता परत: UNSPSC, और उत्पाद जो नहीं जानते कि वे क्या हैं

\n

एक पांचवीं समस्या है जो अपने स्वयं के अनुभाग की हकदार है, क्योंकि यह वह जगह है जहाँ ट्रेड डिस्ट्रीब्यूशन बाजारों से सबसे दूर पीछे है: वर्गीकरण।

\n

मेरे ऑडिट में, एक कैटलॉग के 83% पर श्रेणी फ़ील्ड गायब थे। विशेषता कुंजियों का कोई वर्गीकरण नहीं था - एक 156K-रिकॉर्ड कैटलॉग पर 7,068 अलग-अलग स्पेक कुंजियाँ, उनमें से 64% दस से कम उत्पादों पर उपयोग की जाती हैं, horse_power बनाम horsepower जैसे बहाव के साथ एक ही विशेषता को फ़ेसेट में विभाजित करना। और विवरण जो मैं वापस आता रहता हूं: चार कैटलॉग में से दो में उनकी स्कीमा में UNSPSC फ़ील्ड थे, मैप और तैयार, बिल्कुल शून्य रिकॉर्ड पर आबाद। किसी को पता था कि वर्गीकरण मायने रखता है, स्लॉट बनाया, और कभी नहीं भरा। मैं पैसे पर दांव लगाऊंगा क्यों: एक टैक्सोनॉमी में 300K SKU को हाथ से वर्गीकृत करना कैटलॉग टीम के काम का एक साल है, इसलिए यह हमेशा के लिए रोडमैप पर रहा।

\n

यदि आप B2B के बाहर हैं, तो UNSPSC संयुक्त राष्ट्र मानक उत्पाद और सेवा कोड है, वह वर्गीकरण जो प्रोक्योरमेंट सिस्टम बोलते हैं। यह वह हिस्सा है जो उपभोक्ता सर्च के पास नहीं है: आपके ग्राहकों की खरीद प्रणाली को इसकी आवश्यकता होती है। पंचआउट कैटलॉग, ई-प्रोक्योरमेंट प्लेटफ़ॉर्म और खर्च-विश्लेषण उपकरण UNSPSC कोड के आसपास बनाए गए हैं। एक वितरक जिसका कैटलॉग स्वच्छ कोड रखता है, वह ठेकेदार या अस्पताल की खरीद प्रणाली में प्लग कर सकता है। उनके बिना एक पीडीएफ मूल्य सूची है जिसमें एक सर्च बॉक्स है। आंतरिक रूप से यह श्रेणी फ़ेसेट, श्रेणी-स्कोप्ड रैंकिंग ("एक संख्या जो तार गेज के रूप में पार्स करती है, केवल तार को बढ़ावा देना चाहिए"), क्रॉस-कैटलॉग डेडुप, और श्रेणी 4 में हर विस्तार जनरेटर के लिए संदर्भ गेट को भी शक्ति देता है।

\n

और यह अब एक बैच जॉब है। यह उसी आकार की समस्या है जिसे DoorDash LLM के साथ हल करने का वर्णन करता है - एक नियंत्रित शब्दावली के खिलाफ उच्च-मात्रा लेबलिंग - और दृष्टिकोण सीधे स्थानांतरित होता है:

\n\n

लागत लगभग शर्मनाक है। वर्गीकरण एक छोटा-आउटपुट कार्य है: प्रति रिकॉर्ड लगभग 300 इनपुट टोकन और 30 आउट। बैच एपीआई मूल्य निर्धारण पर Claude Haiku 4.5 पर यह प्रति हजार SKU लगभग 17 सेंट है। मेरा पूरा 775K-रिकॉर्ड बेड़ा लगभग $130 में वर्गीकृत होगा। जो चीज़ वर्षों तक रोडमैप पर रही क्योंकि यह मैन्युअल काम का एक साल था, उसकी लागत उस टीम लंच से कम है जहाँ आप इस पर चर्चा करेंगे।

\n
You classify B2B distributor products into UNSPSC. Attached: the UNSPSC\nfamily list (level 2, ~450 entries) as reference data.\n\nFor each product record (title, description, brand, part number, any existing\ncategory text), output JSON:\n- unspsc_family: the 4-digit family code - choose ONLY from the attached list\n- family_confidence: high | low\n- rationale: one short phrase (e.g. \"copper press fitting -> pipe fittings\")\n\nRules: judge from the product's function, not its brand. Trade shorthand:\nCXC/FPT/MPT are pipe connections, ELL is elbow, CPLG is coupling, a bare\nfraction+material is usually a fitting size. If the record is not a physical\nproduct (freight lines, upcharges, \"*** NOT A PHYSICAL ITEM ***\"), output\nNOT_A_PRODUCT. Use low confidence liberally - low-confidence records get a\nsecond pass with the class-level list.\n
\n

सफाई प्लेबुक, वास्तविक बिल के साथ

\n

फिक्स पाइपलाइन में तीन स्तर हैं और वर्गीकरण कार्य। चाल सही स्तर पर खर्च करना है, क्योंकि आपको लगभग कभी भी प्रति रिकॉर्ड LLM कॉल की आवश्यकता नहीं होती है।

\n
flowchart LR\n    A[\"Tier 0 - Rules
deterministic code
~$0\"] --> B[\"Tier 1 - LLM on unique values
brands · spec keys · units
tens of dollars\"]\n    B --> C[\"Tier 2 - LLM per record
titles · attributes · UNSPSC
hundreds of dollars\"]\n    C --> G[\"Ingest gates
every fix becomes a validator\"]\n
\n

टियर 0 नियतात्मक कोड है और यह मूल रूप से मुफ्त है। HTML स्ट्रिप करें और संस्थाओं को डिकोड करें। सेंटिनल को स्पष्ट फ़्लैग के साथ वास्तविक शून्य में बदलें। UPC की मरम्मत करें (बाएं-पैड, वैज्ञानिक संकेतन अस्वीकार करें, चेक अंक मान्य करें)। यूनिकोड-सामान्य आईडी। पाइप-सीमांकित क्रॉस-रेफरेंस विभाजित करें। PN विविधताओं को छोड़ दें जो किसी अन्य उत्पाद के विहित संख्या से टकराती हैं। मृत स्कीमा हटाएं। एक एजेंट इन स्क्रिप्ट को एक सत्र में लिखता है, और इस स्तर ने मेरे ऑडिट में पाए गए लगभग आधे को ठीक कर दिया। किसी भी संवर्धन से पहले इसे करें, या आप उन उत्पादों के लिए खूबसूरती से शीर्षकों को फिर से लिखने के लिए एक मॉडल को भुगतान करेंगे जिन्हें आपकी पाइपलाइन ने चुपचाप छोड़ दिया।

\n

टियर 1 रिकॉर्ड पर नहीं, अद्वितीय मूल्यों पर LLM चलाता है। यह वह चाल है जो शब्दावली समस्याओं को सस्ता बनाती है: मेरे सबसे खराब कैटलॉग में 313K रिकॉर्ड थे लेकिन केवल 741 अलग-अलग ब्रांड स्ट्रिंग्स थे। ब्रांड सामान्यीकरण 741 स्ट्रिंग्स पर एक काम है - केस विविधताओं को क्लस्टर करें, उप-ब्रांड को माता-पिता पर मैप करें, प्लेसहोल्डर को फ़्लैग करें - 313K कॉल नहीं। स्पेक कुंजियों और इकाई प्रत्ययों के लिए भी यही चाल। प्रत्येक शब्दावली कार्य एकल-अंक डॉलर है और इसका आउटपुट एक स्थिर उपनाम तालिका है जिसे आपका इन्जेस्ट हमेशा के लिए लागू करता है, नियतात्मक रूप से। पूरे स्तर को $20-50 कहें, जो ज्यादातर समीक्षा पास पर खर्च किया जाता है।

\n
Attached: the full distinct-value distribution of my brand and manufacturer\nfields (value, record_count). Produce a normalization table:\n\ncanonical_brand, parent_manufacturer, [raw variants], confidence\n\nRules: cluster case/punctuation/whitespace variants; map sub-brands to parent\nmanufacturers as a separate column (don't merge); mark placeholder values as\nNULL_SENTINEL; mark product lines or categories misfiled as brands as\nNOT_A_BRAND. Flag uncertain clusters rather than guessing. Output CSV, then\nwrite a script that applies it at ingest and logs unmatched new values.\n
\n

टियर 2 प्रति-रिकॉर्ड पास है: एक ग्राहक-पठनीय शीर्षक, सर्च विस्तार, संरचित विशेषताएं, और हर उत्पाद के लिए एक पुनर्प्राप्त निर्माता पार्ट नंबर। प्रति SKU यह छोटा है - लगभग 400 इनपुट टोकन (रिकॉर्ड, साझा निर्देशों के साथ जो प्रॉम्प्ट कैशिंग लगभग मुफ्त बनाती है) और 250 आउट। मॉडल चुनने से पहले दो लीवर: जो लाइव है उसे समृद्ध करें (मेरे सबसे खराब कैटलॉग पर केवल 14% रिकॉर्ड सक्रिय थे, वहीं 86% कटौती), और बैच एपीआई का उपयोग करें जहां प्रदाता के पास है, क्योंकि संवर्धन में कोई विलंबता आवश्यकता नहीं है और Anthropic और OpenAI दोनों बैच के लिए 50% कम करते हैं।

\n

मैंने उसी काम को हर उस चीज़ पर मूल्य दिया जो आप 2026 में उपयोग करेंगे - Claude, GPT-5.6 के तीन स्तर (Sol, Terra, Luna), Kimi K3, GLM-5.2, Qwen3.5, और DeepSeek V4। समान कार्यभार, प्रदाता-प्रकाशित दरें, बैच छूट जहां मौजूद है:

\n

\"Cost

\n

मुझे इन नंबरों की दोबारा जांच करनी पड़ी क्योंकि वे गलत लग रहे थे। इस परियोजना का सबसे खराब स्थिति संस्करण - एक सीमा मॉडल, हर एक SKU, कोई फ़िल्टरिंग नहीं - लगभग $3,800 पर शीर्ष पर है। मंजिल सौ डॉलर से कम है: DeepSeek V4-Flash एक अच्छी ड्रिल की कीमत के लिए पूरे बेड़े को समृद्ध करेगा। जो संस्करण आप वास्तव में चलाएंगे वह स्तरों को मिलाता है: यांत्रिक बहुमत के लिए एक बजट मॉडल (Haiku, Luna, Qwen Flash, DeepSeek), संक्षिप्त-सलाद पूंछ के लिए एक मध्य-स्तरीय मॉडल (Sonnet, Terra, GLM-5.2) जिसे छोटा मॉडल कम-आत्मविश्वास के रूप में फ़्लैग करता है, और एक सीमा मॉडल 1-2% नमूने की जांच गुणवत्ता गेट के रूप में करता है। यह आपके द्वारा चुने गए विक्रेताओं की परवाह किए बिना लाइव SKU के लिए कुछ सौ डॉलर पर उतरता है।

\n

दो चेतावनियाँ जो चार्ट नहीं दिखा सकता। सस्ते मॉडल केवल सस्ते होते हैं यदि उनका आउटपुट आपके मूल्यांकन से बचता है - प्रतिबद्ध होने से पहले 200-नमूना तुलना चलाएं, क्योंकि एक बजट मॉडल जो 5% पार्ट नंबरों को विकृत करता है, उस सीमा मॉडल से अधिक खर्च करता है जो नहीं करता है। और आपका कैटलॉग प्रतिस्पर्धी डेटा है: मूल्य निर्धारण, क्रॉस-रेफरेंस और ग्राहक पार्ट नंबर उन रिकॉर्डों में हैं, इसलिए सूची में सबसे सस्ते एंडपॉइंट पर 775K रिकॉर्ड भेजने से पहले प्रत्येक प्रदाता की डेटा-प्रतिधारण और प्रशिक्षण शर्तों की जांच करें। कई वितरकों के लिए अकेले वह जांच कुछ विक्रेताओं को अंदर या बाहर करती है, और ओपन-वेट विकल्पों (DeepSeek, GLM, Qwen, Kimi) में अतिरिक्त संपत्ति है कि आप उन्हें स्वयं-होस्ट कर सकते हैं यदि डेटा बिल्कुल नहीं छोड़ सकता है।

\n

लगभग $130 UNSPSC पास (जो मॉडलों में उसी तरह स्केल करता है - बजट स्तर पर यह जेब बदलने के लिए गिर जाता है) और शब्दावली कार्य जोड़ें, और पूरा कैटलॉग परिवर्तन कुछ सौ और कुछ हज़ार डॉलर के बीच चलता है, उस काम के खिलाफ जो एक मर्चेंडाइजिंग टीम का वर्ष हुआ करता था। यह वही ऑफ़लाइन-बैच अर्थशास्त्र है जो Instacart वर्णन करता है, बस ट्रेड-कैटलॉग पैमाने पर जहां संख्याएं क्रेडिट कार्ड पर रखने के लिए पर्याप्त छोटी हो जाती हैं।

\n

यह मेरे ऑडिट से एक वास्तविक रिकॉर्ड पर कैसा दिखता है:

\n
IN:  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:         high\n
\n

extracted_mpn लाइन देखें। वही पास निर्माता पार्ट नंबरों को पुनर्प्राप्त करता है जो पहले विवरण पाठ में दबे हुए थे - मेरे एक कैटलॉग पर यह 183K उत्पाद बॉक्स पर मुद्रित संख्या से खोजने योग्य हो जाते हैं। अकेले वह बैच जॉब के लिए भुगतान करता है।

\n
You enrich B2B distributor product records for search. For each input record\n(raw ERP name, descriptions, brand, part number, category) produce JSON:\n\n- display_title: customer-readable, <=80 chars, Title Case. Expand trade\n  abbreviations (CXC -> copper x copper connection, ELL -> elbow, CPLG ->\n  coupling, RED -> reducing). Keep every part number, model code, and\n  dimension VERBATIM as typed - never spell codes out in words.\n- search_expansions: 2-5 phrases a customer might type that don't appear in\n  the raw text (plain-English product type, common trade names). Never invent\n  specs absent from the source.\n- attributes: {name: {value, unit}} extracted ONLY from the source text.\n- extracted_mpn: manufacturer part number if present in the description text\n  (usually the token after the brand) and absent from the PN fields, else null.\n- confidence: high | low. Use low whenever you had to guess; a low answer\n  routed to review beats a confident hallucination.\n
\n

दो उत्पादन नोट: साझा निर्देशों को एक कैश्ड प्रॉम्प्ट उपसर्ग में रखें (कैशिंग बैच छूट के शीर्ष पर इनपुट पक्ष को 90% तक कम कर देता है), और JSON स्कीमा के साथ संरचित आउटपुट का उपयोग करें ताकि आप कभी भी पार्स-विफलता कर का भुगतान न करें।

\n

अंतिम स्तर वह है जिसे लोग छोड़ देते हैं, और यह वह है जो चक्रवृद्धि करता है। ऑडिट एक सफाई के लायक है। यह जो वैलिडेटर उत्पन्न करता है वह हर भविष्य के फ़ीड के लायक है। फिक्स सत्र समाप्त करें:

\n
Turn every issue we just fixed into an automated check that fails the ingest\npipeline loudly: derived-field coverage assertions, sentinel blocklists, type\nassertions on text fields, identifier checksum validation, PN-variant\ncollision checks, id hygiene rules, UNSPSC coverage tracking, and a data-\nfreshness alarm per catalog. Emit them as tests CI runs against a sample of\nevery new feed.\n
\n

इसे छोड़ दें और वही ERP निर्यात एक चौथाई के भीतर उसी कचरे को पुन: उत्पन्न करेगा, और आप सफाई के लिए दो बार भुगतान करेंगे। मैं जानता हूं क्योंकि मेरे ऑडिट में पाए गए दो बग स्पष्ट रूप से पहले तय किए गए थे, और वापस आ गए थे।

\n

प्रॉम्प्ट चलाना

\n

एक सेटअप चरण: अपने कैटलॉग को JSONL में डंप करें, प्रति पंक्ति एक JSON ऑब्जेक्ट जिसमें एक अद्वितीय id और रिकॉर्ड के फ़ील्ड हों। आपका प्लेटफ़ॉर्म जो भी हो - Elasticsearch, OpenSearch, Solr, Algolia, Typesense, एक PIM, उसके पीछे डेटाबेस - बस एजेंट से एक्सपोर्टर लिखने के लिए कहें:

\n
Write a script that exports every product record from my catalog [describe:\nsearch index name / database table / PIM export] to ./dump/records-{n}.jsonl\nin 50k-record chunks - one JSON object per line with a unique \"id\" plus all\nfields - and my field/schema definition (if the platform has one) to\nschema.json. Verify the exported count matches the source count.\n
\n

Claude Code के साथ, उस निर्देशिका में एक सत्र में किसी भी श्रेणी प्रॉम्प्ट को छोड़ दें। यह विश्लेषण स्वयं लिखता और चलाता है, नमूने के बहाने के बिना पूर्ण पास, और रिकॉर्ड-स्तरीय रसीदों के साथ वापस आता है। जब आप कहते हैं "अब इसे ठीक करें", वही सत्र इन्जेस्ट वैलिडेटर, बैकफिल स्क्रिप्ट और बैच-संवर्धन कार्य उत्पन्न करता है। श्रेणियों को समानांतर सत्रों या सबएजेंट के रूप में चलाएं; मैंने अपना ऐसे ही चलाया, और पूरे ऑडिट में लगभग बारह मिनट की दीवार-घड़ी का समय लगा। Codex के साथ, codex exec समान प्रॉम्प्ट का उपयोग करके केवल-पढ़ने के विश्लेषण पास संभालता है; लेखन-पक्ष फिक्स को एक सत्र में रखें जिसकी आप समीक्षा करते हैं।

\n

तीन नियम जो मैंने कठिन तरीके से सीखे:

\n
    \n
  1. पूर्ण पास और रसीदों की मांग करें। "इस डेटा का विश्लेषण करें" नमूने और वाइब्स को आमंत्रित करता है। प्रति निष्कर्ष सटीक गणना और पांच उदाहरण रिकॉर्ड आईडी मांगें, और हर दावा जांचने योग्य हो जाता है।
    2. \n
  2. संवर्धन से पहले नियम। कथा जोड़ने से पहले सत्य को ठीक करें, या आप "Approved Vendor" लेबल वाले 88% रिकॉर्ड के लिए ब्रांडों को मतिभ्रम करेंगे।
    3. \n
  3. नमूना, मूल्यांकन, फिर बैच। एक अमान्य प्रॉम्प्ट से 775K-रिकॉर्ड बैच कभी न चलाएं। 200 नमूने, एक स्कोरिंग पास, फिर स्केल। मूल्यांकन हार्नेस एक एजेंट सत्र खर्च करता है और पूरे खर्च को जोखिम से बाहर करता है।
    4. \n
\n

व्यापार बाजार-ग्रेड सर्च के हकदार हैं

\n

Amazon, DoorDash और Instacart ने अपने कैटलॉग-LLM काम को दान के रूप में प्रकाशित नहीं किया। उन्होंने इसे प्रकाशित किया क्योंकि तकनीकें सामान्य हैं और खाई निष्पादन है। और तकनीकें ट्रेड डिस्ट्रीब्यूशन में लगभग कहीं और से बेहतर स्थानांतरित होती हैं जो मैं सोच सकता हूं: कैटलॉग इतने छोटे हैं कि एक पूर्ण पास सस्ता है, डेटा इतना खराब है कि हेडरूम बहुत बड़ा है, क्वेरी वास्तविक पैसा ले जाती हैं, और प्रोक्योरमेंट दुनिया पहले से ही एक टैक्सोनॉमी पर चलती है जिसे एक बैच जॉब अब लगभग $130 में आबाद कर सकता है।

\n

मेरे ऑडिट में चार वितरक कैटलॉग में सामने आए दर्जनों मुद्दों में से, एक भी रैंकिंग परत से दिखाई नहीं दे रहा था। उन सभी ने इसे खराब कर दिया। उन इंडेक्स को खिलाने वाली आपूर्ति श्रृंखला - ERP निर्यात, आपूर्तिकर्ता स्प्रेडशीट, प्राचीन CSV पार्सर - बिल्कुल वही है जो प्रकाशित प्लेबुक ठीक करती है। जो वितरक इसे चलाते हैं उनके पास उन कैटलॉग पर बाजार-ग्रेड सर्च होगा जहां उनके प्रतिस्पर्धी अभी भी कंडेनसर कॉइल नहीं ढूंढ सकते हैं।

\n

प्रश्न "क्या मेरे डेटा में कुछ गड़बड़ है?" किसी के समय के दो सप्ताह खर्च करता था, यही कारण है कि किसी ने नहीं पूछा। अब इसकी लागत एक प्रॉम्प्ट है। इसे पूछें।

", "source_hash": "sha256:729970b39c1b22c143ba55272659d6cc431b0f8889282089a4ea4eaa71f75000", "model": "~deepseek/deepseek-v4-flash-latest", "generated_at": "2026-08-06T08:39:22.406307+00:00" }