Thenlper: GTE-Large

Thenlper: GTE-Large, Thenlper का एक embedding मॉडल है, जो api14 पर मॉडल आईडी thenlper/gte-large के तहत सूचीबद्ध है। यह embeddings श्रेणी में आता है, जिसका अर्थ है कि इसका काम चैट जवाब उत्पन्न करना नहीं, बल्कि टेक्स्ट को वैक्टर में बदलना है जिन्हें आप संग्रहीत, तुलना और खोज सकते हैं। यदि आपका एप्लिकेशन खुली-अंत वाली जनरेशन के बजाय semantic similarity पर निर्भर करता है, तो यह उस प्रकार का मॉडल है जिसका आप मूल्यांकन करेंगे।

मॉडल टेक्स्ट इनपुट स्वीकार करता है और आउटपुट के रूप में embeddings उत्पन्न करता है। प्रदाता विवरण के अनुसार, यह अंग्रेजी वाक्यों, अनुच्छेदों और मध्यम-लंबाई के दस्तावेजों को 1024-आयामी सघन वेक्टर स्पेस में परिवर्तित करता है, जिसका घोषित लक्ष्य सूचना पुनर्प्राप्ति, semantic textual similarity और reranking के लिए अनुकूलित उच्च-गुणवत्ता वाले semantic embeddings है। संदर्भ विंडो 512 टोकन है, और अधिकतम आउटपुट 460 है। चूंकि इनपुट मोडलिटी केवल टेक्स्ट है, यहां कोई छवि या ऑडियो प्रबंधन नहीं है, और आउटपुट गद्य के बजाय एक वेक्टर है।

ये क्षमताएं उपयोग के मामलों के एक काफी विशिष्ट समूह की ओर इशारा करती हैं। सूचना पुनर्प्राप्ति स्पष्ट है: अपने दस्तावेजों को एक बार embed करें, अनुरोध के समय उपयोगकर्ता क्वेरी को embed करें, और वेक्टर similarity के आधार पर रैंक करें। Semantic textual similarity सीधे इसका अनुसरण करता है, जो डुप्लिकेशन हटाने, क्लस्टरिंग या ऐसे paraphrases का मिलान करने के लिए उपयोगी है जिनमें बहुत कम शब्दावली साझा होती है। Reranking का भी प्रदाता विवरण में नाम दिया गया है, इसलिए आप इस मॉडल का उपयोग किसी सस्ते प्रथम-चरण retriever द्वारा उत्पन्न उम्मीदवारों की शॉर्टलिस्ट को फिर से स्कोर करने के लिए कर सकते हैं। 512-टोकन संदर्भ वाक्यों, अनुच्छेदों और मध्यम-लंबाई के दस्तावेजों के लिए उपयुक्त है, इसलिए लंबी सामग्री को embed करने से पहले chunking करना अपेक्षित पैटर्न है।

आप इसे मॉडल आईडी thenlper/gte-large का उपयोग करके api14 के OpenAI-संगत API के माध्यम से कॉल करते हैं। चूंकि API OpenAI प्रारूप का अनुसरण करता है, आप अपने मौजूदा client को api14 के base URL पर इंगित करते हैं और अनुरोध में उस आईडी को पास करते हैं। इस मॉडल के लिए समर्थित parameters की सूची खाली है, इसलिए endpoint को जो आवश्यक है उसके अलावा कोई अतिरिक्त अनुरोध parameters सेट करने के लिए नहीं हैं; आप अपना टेक्स्ट भेजते हैं और प्रतिक्रिया से embedding पढ़ते हैं। अनुरोध पक्ष पर ट्यून करने के लिए कुछ नहीं है, जो एकीकरण को सरल बनाए रखता है यदि आपके पास पहले से एक embeddings pipeline है।

योजना बनाने के लिए मुख्य बाधा 512-टोकन संदर्भ विंडो है। लंबे दस्तावेजों को chunks में विभाजित करने की आवश्यकता होती है, और किसी भी retrieval डिज़ाइन को इसका हिसाब रखना होगा। मॉडल को अंग्रेजी टेक्स्ट के साथ काम करने के रूप में वर्णित किया गया है, इसलिए अन्य भाषाएं प्रदाता विवरण के दायरे से बाहर हैं। और चूंकि यह केवल embeddings उत्पन्न करता है, यह अपने आप प्रश्नों का उत्तर नहीं दे सकता या टेक्स्ट नहीं लिख सकता; यदि आपको जनरेशन की आवश्यकता है, तो आप इस मॉडल को अकेले उपयोग करने के बजाय एक अलग भाषा मॉडल के साथ जोड़ेंगे।