एक चरण-दर-चरण विवरण कि Entity Enricher एक अकेली entity को कैसे प्रोसेस करता है — इनपुट से लेकर classification, समानांतर model निष्पादन, और संरचित आउटपुट तक।
Workflow Editor पेज खोलें और अपना संवर्धन सेट अप करें। एक वर्कफ़्लो स्टेपर आपको पाइपलाइन के चरणों से होकर ले जाता है: Sample Data, Schema, Enrichment और Results — और जब स्कीमा किसी Database Sync से जुड़ा हो, तो एक Database चरण भी, जो पुष्टि करता है कि रन के बदलाव आपके डेटाबेस के लिए कतार में लगा दिए गए हैं (या बताता है कि सेव क्यों अस्वीकार हुआ)।
schema स्वतः जनरेट करने के लिए सैंपल JSON पेस्ट करें, फिर इंटरैक्टिव प्रॉपर्टी ट्री एक्सप्लोर करें। प्रॉपर्टीज़ एडिट करें, expertise domain जोड़ें, और फ़ील्ड्स को search key या संरक्षित के रूप में चिह्नित करें।
एनरिचमेंट विकल्प (स्ट्रैटेजी, मॉडल, भाषाएँ, क्लासिफ़िकेशन, साथ ही रिस्पॉन्स स्कीमा और स्ट्रिक्ट स्ट्रक्चर्ड आउटपुट टॉगल) कॉन्फ़िगर करें और एंटिटी की पहचान के लिए एंटिटी सर्च कीज़ (नाम, वेबसाइट, देश आदि) भरें।
प्रत्येक मॉडल के लिए रियल-टाइम प्रगति और परिणाम दिखाता है। एकाधिक मॉडल उपयोग करते समय, फ्यूज़न के लिए एक “Merge Results” बटन दिखाई देता है।
कुछ रिक्वेस्ट किसी भी हाल में काम का परिणाम नहीं दे सकतीं, और यह पता लगाने की सबसे सस्ती जगह पहली LLM कॉल से पहले है। शुरुआत में ही दो कॉन्ट्रैक्ट लागू किए जाते हैं।
स्कीमा बताता है कि उसके इनपुट में क्या होना ज़रूरी है: वे की फ़ील्ड जो बताती हैं कि यह कौन-सी एंटिटी है, आपके दिए गए ऐरे की हर आइटम पर एक की, और preserve चिह्नित हर फ़ील्ड का एक मान (जो कभी दिया ही नहीं गया, उसे संरक्षित नहीं किया जा सकता)। इनमें से कुछ भी छूटने पर अनुरोध एक ही एरर के साथ अस्वीकार होता है, जो सभी उल्लंघन एक साथ सूचीबद्ध करता है — साथ में स्कीमा का पूरा कॉन्ट्रैक्ट भी, ताकि आप एक ही बार में सुधार कर सकें, बजाय एक-एक अस्वीकृति से आवश्यकताएँ पता करने के। यह कॉन्ट्रैक्ट हर सहेजे गए स्कीमा पर प्रकाशित होता है, ताकि क्लाइंट भेजने से पहले जाँच सके।
आप जिस ऐरे के आइटम देते हैं उसे ठीक उतना ही संवर्धित किया जाता है: मॉडल हर आइटम के बारे में जो जानता है वह भरता है और न कोई आइटम जोड़ सकता है, न हटा सकता है। आपने पाँच लाइन आइटम भेजे, तो पाँच ही वापस मिलेंगे। जिस आइटम को मॉडल नहीं पहचान पाया, उसे खोने के बजाय हूबहू दोबारा डाल दिया जाता है, और जो आइटम उसने गढ़ लिया उसे हटा दिया जाता है। जिन ऐरे को आप खाली छोड़ते हैं वे फिर भी खुले रहते हैं — वहीं मॉडल नए तथ्य खोजता है, और यही मक़सद है।
यदि आपने एक classification model चुना है, तो entity schema प्रकार से मेल खाती है या नहीं यह सत्यापित करने के लिए पहले एक तेज़, सस्ता LLM call चलता है। यह entity के मेल न खाने पर enrichment में token बर्बाद होने से रोकता है। अधिक जानकारी Classification दस्तावेज़ीकरण में पढ़ें।
चुना गया हर मॉडल एंटिटी को उस स्ट्रैटेजी से प्रोसेस करता है जो आपने बताई है — या डिफ़ॉल्ट रूप से, उस स्ट्रैटेजी से जो आपके स्कीमा के आकार से अपने आप चुनी जाती है और जिसे रन शुरू होते समय बताता है। जब कई मॉडल चुने जाते हैं, तो वे प्रोवाइडरों के बीच समानांतर चलते हैं (Claude और GPT-4 एक साथ चलते हैं), जबकि एक ही प्रोवाइडर के मॉडल रेट लिमिट का ध्यान रखते हुए क्रमवार चलते हैं।
हर LLM प्रतिक्रिया को रीयल-टाइम में आपके schema के विरुद्ध सत्यापित किया जाता है। जब आउटपुट अपेक्षित प्रकारों या बाधाओं से मेल नहीं खाता, तो सिस्टम सुधार के लिए स्वतः त्रुटियाँ वापस LLM को भेज देता है।
प्रति LLM कॉल अधिकतम 5 स्वतः रीट्राई प्रयास। हर रीट्राई में वह विशिष्ट वैलिडेशन एरर शामिल होता है ताकि LLM को ठीक-ठीक पता हो कि क्या ठीक करना है — और मरम्मत सर्जिकल होती है: पूरे जवाब के बजाय सिर्फ़ वही लीफ़ दोबारा पूछे जाते हैं जो गलत आए थे।
ध्यान दें कि इस सूची में क्या नहीं है: जो मान मॉडल तय नहीं कर सका, वह दोबारा कोशिश करने लायक त्रुटि नहीं है। हर फ़ील्ड अनुपस्थित लौट सकता है, और मॉडल घोषित करता है कि उसे क्या नहीं मिला, इसलिए “अज्ञात” विफलता नहीं बल्कि एक उत्तर है। कोई गुम मान स्वीकार्य है या नहीं, यह बाद में तय होता है — जब एंटिटी आपके डेटाबेस में प्रवेश पाती है, न कि मॉडल से अनुमान लगवाकर।
दो वैकल्पिक टॉगल provider से आउटपुट को वापस आने से पहले सीमित करने के लिए कहते हैं, ताकि शुरुआत में ही कम responses को सुधारने की ज़रूरत पड़े। दोनों केवल उन models पर लागू होते हैं जो इन्हें सपोर्ट करते हैं; बाकी सब कुछ ऊपर बताए गए validation-और-retry लूप पर वापस आ जाता है।
Entity Enricher वास्तविक समय में प्रगति स्ट्रीम करने के लिए Server-Sent Events (SSE) का उपयोग करता है। आपको सभी मॉडल के पूरा होने की प्रतीक्षा नहीं करनी पड़ती — जैसे-जैसे प्रत्येक विशेषज्ञता डोमेन या मॉडल समाप्त होता है, परिणाम क्रमिक रूप से दिखाई देते हैं।
हर model को अपना परिणाम पैनल मिलता है जो संरचित JSON आउटपुट, प्रति-expertise प्रगति बैज, टोकन उपयोग, लागत, और प्रोसेसिंग समय दिखाता है। multi-expertise रणनीति का उपयोग करते समय, जैसे ही हर domain पूरा होता है expertise बैज रीयल-टाइम में अपडेट होते हैं।
मल्टी-विशेषज्ञता रणनीति का उपयोग करते समय, कुछ विशेषज्ञताएं विफल हो सकती हैं जबकि अन्य सफल होती हैं। सब कुछ त्यागने के बजाय, Entity Enricher सफल विशेषज्ञताओं का मर्ज किया हुआ आउटपुट “Partial” स्थिति के साथ लौटाता है। फिर आप पूरी एनरिचमेंट को दोबारा चलाए बिना केवल विफल विशेषज्ञताओं को पुनः प्रयास कर सकते हैं।
एनरिचमेंट पूरा होने के बाद, आपके परिणाम भविष्य के संदर्भ के लिए History पेज पर सहेजे जाते हैं। यदि आपने कई मॉडल इस्तेमाल किए हैं, तो आप Multi-Model फ्यूज़न का उपयोग करके परिणामों को मर्ज कर सकते हैं।