प्री-फ्लाइट क्लासिफिकेशन यह सत्यापित करता है कि एनरिचमेंट शुरू होने से पहले कोई एंटिटी अपेक्षित स्कीमा प्रकार से मेल खाती है। यह वैकल्पिक चरण तब हैलुसिनेशन और टोकन की बर्बादी को रोकता है जब एंटिटी आपके स्कीमा से मेल नहीं खातीं।
LLM मदद करने के लिए उत्सुक रहते हैं। जब किसी स्कीमा के विरुद्ध एंटिटी को एनरिच करने को कहा जाता है, तो वे संरचित आउटपुट तैयार कर देते हैं, भले ही एंटिटी स्कीमा टाइप से बिल्कुल मेल न खाती हो। इससे हैलुसिनेटेड डेटा बनता है जो संभावित लगता है पर पूरी तरह गलत होता है।
Schema: “Planet” — Entity: “Titan”
LLM Titan को एक ग्रह मानता है और डेटा गढ़ लेता है: ऑर्बिटल पीरियड, वायुमंडल संरचना, चंद्रमाओं की संख्या — सभी विश्वसनीय दिखने वाले पर गलत। Titan असल में Saturn का एक चंद्रमा है।
क्लासिफिकेशन पता लगाता है: “बेमेल — Titan एक चंद्रमा है, ग्रह नहीं”
एनरिचमेंट मॉडल इस संदर्भ को प्राप्त करते हैं, असंगत फ़ील्ड को null पर सेट करते हैं, और केवल उन प्रॉपर्टीज़ को भरते हैं जो वास्तव में एंटिटी पर लागू होती हैं।
किसी भी एनरिचमेंट मॉडल के शुरू होने से पहले क्लासिफिकेशन एक एकल, तेज़ LLM कॉल के रूप में चलता है। लागत कम करने के लिए यह एक सस्ते, त्वरित मॉडल (जैसे Claude Haiku या GPT-4o Mini) का उपयोग करता है।
एंटिटी स्कीमा प्रकार से मेल खाती है। एनरिचमेंट उच्च आत्मविश्वास के साथ आगे बढ़ता है।
एंटिटी स्कीमा की अपेक्षा से भिन्न प्रकार की है। क्लासिफिकेशन बताता है कि एंटिटी वास्तव में क्या है।
एंटिटी की निश्चित रूप से पहचान नहीं की जा सकती। LLM के पास इसे वर्गीकृत करने के लिए पर्याप्त जानकारी नहीं है।
कई मान्य व्याख्याएँ मौजूद हैं। वर्गीकरण विकल्पों को सूचीबद्ध करता है।
क्लासिफिकेशन पूरी तरह सलाहकारी है। यदि किसी भी कारण से क्लासिफिकेशन कॉल विफल होता है (मॉडल त्रुटि, टाइमआउट, रेट लिमिट), तो एनरिचमेंट क्लासिफिकेशन संदर्भ के बिना सामान्य रूप से आगे बढ़ता है। इससे सुनिश्चित होता है कि वैकल्पिक क्लासिफिकेशन चरण कभी भी एनरिचमेंट के पूरा होने में बाधा न बने।
क्लासिफिकेशन को तेज़, सस्ते मॉडलों पर चलाने के लिए डिज़ाइन किया गया है। यह एक न्यूनतम पेलोड (स्कीमा नाम, विवरण, और छोटा किया गया एंटिटी डेटा) भेजता है और एक छोटी संरचित प्रतिक्रिया की अपेक्षा करता है। सामान्य लागत एनरिचमेंट का एक अंश होती है — सटीकता में सुधार के लिए यह पूरी तरह उपयुक्त है।
UI, Server-Sent Events के माध्यम से क्लासिफिकेशन की प्रगति रीयल-टाइम में दिखाता है। जब जाँच शुरू होती है तो एक classification_started इवेंट ट्रिगर होता है, जिसके बाद स्टेटस, कॉन्फिडेंस और एंटिटी विवरण के साथ classification_completed आता है। परिणाम मॉडल परिणामों के ऊपर एक बैनर के रूप में दिखाई देता है।
यदि आप classification चरण के दौरान enrichment रद्द करते हैं, तो job किसी भी enrichment model को शुरू किए बिना तुरंत रुक जाता है। कोई अनावश्यक token खर्च नहीं होता।
Workflow Editor या Batch Enrichment साइडबार में, “Classification” ड्रॉपडाउन खोजें। एक तेज़, कम खर्चीला मॉडल चुनें (Claude Haiku, GPT-4o Mini, या समान)। हर एंटिटी के लिए एनरिचमेंट शुरू होने से पहले क्लासिफिकेशन स्वचालित रूप से चलेगा।
REST API का उपयोग करते समय, अपने एनरिचमेंट अनुरोध में मॉडल की कंपोज़िट कुंजी के साथ classification_model फ़ील्ड शामिल करें (जैसे, anthropic::claude-haiku-4-5)।
हर जाँच हिस्ट्री में क्लासिफिकेशन टाइप के अंतर्गत अपने अलग रिकॉर्ड के रूप में रखी जाती है, ताकि आप हमेशा देख सकें कि किसी रन के बारे में चेतावनी क्यों दी गई थी।
इसे भ्रमित न करें database-model क्लासिफिकेशन के साथ, जिसके साथ सिर्फ़ शब्द समान है और कुछ नहीं: वह तब चलता है जब कोई स्कीमा किसी database sync से जुड़ा हो, और हर प्रॉपर्टी की डेटाबेस key, SQL टाइप और इंडेक्स इंटेंट प्रस्तावित करता है — एक सर्च कॉलम जो टेक्स्ट फ़्रैगमेंट से मैच होता है, किसी कोऑर्डिनेट या इंटरवल जोड़ी का एक हिस्सा जो मिलकर एक ही स्पेशियल या रेंज इंडेक्स बनता है, या एक क्वेरी-शेप्ड इंडेक्स: किसी ऑब्जेक्ट के फ़ील्ड्स की क्रमबद्ध सूची, जो उस लिस्ट-स्क्रीन क्वेरी के आकार में होती है जिसे वह सर्व करती है, और एक ही मल्टी-कॉलम इंडेक्स के रूप में भेजी जाती है। यह आपकी एंटिटी के बारे में कुछ नहीं पूछता और History में DB Classification के रूप में दिखता है।