विचार नेता
सबसे कैपेबल एआई मॉडल आपके ऐप के लिए हमेशा सही विकल्प नहीं होता
Unite.AI को Google पर अपने पसंदीदा स्रोतों में जोड़ें
सबसे शक्तिशाली मॉडल का चयन करने में एक निश्चित सुख है। जब आप एक एआई-संचालित उत्पाद बना रहे हों, तो सबसे शक्तिशाली मॉडल का चयन करना जिम्मेदारी (लगभग तर्कसंगत) लगता है। जीपीटी-4ओ, क्लॉड ओपस, जेमिनी अल्ट्रा। ये प्रभावशाली तकनीक के टुकड़े हैं, और किसी ने कभी सबसे चतुर उपकरण का चयन करने के लिए निकाला नहीं है।
सिवाय, खैर, एक अस्वीकरण है। परियोजनाएं फूल जाती हैं। लागत बढ़ जाती है। देरी आ जाती है। और लगभग तीन महीने के आसपास, टीम असहज प्रश्न पूछना शुरू कर देती है कि क्यों एक सरल ऑटोकम्प्लीट सुविधा एपीआई क्रेडिट के माध्यम से जल रही है जैसे कि एक स्टार्टअप जिसमें वेंचर फंडिंग और कोई जवाबदेही नहीं है।
यह बात है: “सबसे कैपेबल” और “सबसे उपयुक्त” दो अलग-अलग मानक हैं। एआई ऐप विकास सेवाओं के प्रदाता मॉडल का चयन मूल्यांकन द्वारा करते हैं, नेतृत्व रैंकिंग द्वारा नहीं।
बड़ा हमेशा बेहतर नहीं होता
एक फ्रंटियर मॉडल आदर्श परिस्थितियों में असाधारण रूप से अच्छा प्रदर्शन करता है, लेकिन संचालित करने के लिए बहुत महंगा है, अपूर्ण इनपुट को खराब तरीके से संभालता है, और सरल कार्यों के लिए आवश्यकताओं से अधिक है।
जीपीटी-4ओ कविता लिख सकता है, कानूनी अनुबंधों के माध्यम से तर्क कर सकता है, कोड डीबग कर सकता है, और एक दस साल के बच्चे को क्वांटम एंटैंगलमेंट की व्याख्या कर सकता है, कभी-कभी एक ही प्रतिक्रिया में। यह वास्तव में उल्लेखनीय है। लेकिन अगर आपका ऐप ग्राहक सहायता टिकटों का सारांश बना रहा है या इनवॉइस से संरचित डेटा निकाल रहा है, तो आप अप्रयुक्त क्षमताओं के लिए भुगतान कर रहे हैं।
छोटे, विशेष मॉडल ध्यान केंद्रित कार्यों के साथ आश्चर्यजनक सटीकता से निपटते हैं:
- जीपीटी-4ओ मिनी लगभग 15 गुना कम लागत पर अधिकांश भाषा कार्यों को कवर करता है
- क्लॉड हाइकु उच्च-मात्रा वाले संरचित कार्यभार पर गति और दक्षता के लिए निर्मित है
- मिस्ट्रल 7बी और लामा 3.1 8बी खुले स्रोत विकल्प हैं जो तेजी से चलते हैं और ठीक से ट्यून होते हैं
इन और फ्रंटियर मॉडल के बीच की खाई कार्य संकीर्ण होने और प्रोम्प्ट अच्छी तरह से इंजीनियर होने पर काफी कम हो जाती है।
लागत गणित जिसे योजना बैठकों में कोई नहीं बात करता
फ्रंटियर मॉडल के लिए एपीआई मूल्य निर्धारण उनके हल्के समकक्षों की तुलना में प्रति टोकन 10 से 30 गुना अधिक हो सकता है। यह अंतर स abstract लगता है जब तक आप इसे बड़े पैमाने पर मॉडल नहीं करते।
मान लें कि आपका ऐप प्रति माह 500,000 एपीआई कॉल करता है:
| मॉडल | अनुमानित मासिक लागत |
| जीपीटी-4ओ | $1,500 – $3,000 |
| जीपीटी-4ओ मिनी | $150 – $300 |
| क्लॉड हाइकु | $125 – $250 |
एक ही सुविधा। बहुत अलग मार्जिन कहानी।
कुछ टीमें हाइब्रिड आर्किटेक्चर चलाती हैं, सरल वर्गीकरण कार्यों को हल्के मॉडलों में मार्गदर्शन करती हैं जबकि भारी मॉडलों को जटिल पीढ़ी या तर्क चरणों के लिए आरक्षित करती हैं। मार्टियन और राउटेलएम जैसी कंपनियों ने इस तरह के मॉडल मार्गदर्शन के लिए विशेष रूप से टूलिंग बनाई है। यह ग्लैमरस इंजीनियरिंग नहीं है, लेकिन यह वह चीज है जो सीएफओ को ध्यान देने योग्य रूप से अधिक आरामदायक बनाती है।
देरी एक उपयोगकर्ता अनुभव समस्या है
एक कारण है कि फास्ट फूड अस्तित्व में है। लोग हमेशा पांच-कोर्स भोजन नहीं चाहते हैं। कभी-कभी वे अपना उत्तर अब चाहते हैं।
फ्रंटियर मॉडल धीमे हैं। हमेशा बहुत नहीं, लेकिन पर्याप्त रूप से मायने रखता है वास्तविक समय अनुप्रयोगों में। यदि आपके उपयोगकर्ता एक संवादात्मक यूआई, एक चैट इंटरफ़ेस या एक लाइव कोडिंग सहायक में एआई प्रतिक्रियाओं की प्रतीक्षा कर रहे हैं, तो प्रतिक्रिया देरी सीधे तौर पर यह महसूस करती है कि उत्पाद कैसा लगता है। 4-6 सेकंड में प्रतिक्रिया देने वाला मॉडल अस्थिर महसूस करना शुरू कर देता है, भले ही आउटपुट तकनीकी रूप से श्रेष्ठ हो।
नियम का अंगूठा: यदि उपयोगकर्ता एक लोडिंग स्पिनर देखता है, तो प्रत्येक अतिरिक्त सेकंड विश्वास को कम करता है।
हाइकु, मिस्ट्रल और लामा 3.1 8बी समान लोड स्थितियों के तहत काफी तेजी से चलते हैं (कभी-कभी 3 से 5 गुना तेज)। उपयोगकर्ता-सामना करने वाली सुविधाओं के लिए जहां धारणा की गई गति का महत्व है, यह एक छोटी सी बात नहीं है। यह एक उत्पाद निर्णय है।
प्रॉम्प्ट इंजीनियरिंग परिवर्तनीय (जो सब कुछ बदल देता है)
यहाँ कुछ ऐसा है जो मॉडल तुलना थ्रेड्स में छूट जाता है: एक छोटे मॉडल पर एक अच्छी तरह से तैयार प्रॉम्प्ट अक्सर एक फ्रंटियर मॉडल पर एक आलसी प्रॉम्प्ट को हरा देता है।
आउटपुट गुणवत्ता मॉडल क्षमता और प्रॉम्प्ट गुणवत्ता का उत्पाद है। जब टीमें प्रॉम्प्ट इंजीनियरिंग (स्पष्ट निर्देश, संरचित आउटपुट प्रारूप, कुछ शॉट उदाहरण, अच्छी तरह से परिभाषित प्रतिबंध) में निवेश करती हैं, तो छोटे मॉडल अपने स्पष्ट छत से काफी ऊपर प्रदर्शन करते हैं।
यहाँ कुछ उपकरण हैं जो जानने योग्य हैं:
- लैंगचेन और डीएसपीआई प्रॉम्प्ट पाइपलाइनों की रचना और अनुकूलन के लिए
- संरचित आउटपुट के लिए निर्देशित और प्रतिबंधित पीढ़ी के लिए
- मॉडल के साथ प्रणालीगत प्रॉम्प्ट मूल्यांकन चलाने के लिए प्रॉम्प्टफू
उत्पादन में आज की सबसे प्रभावशाली एआई सुविधाओं में से कुछ मॉडल पर चल रहे हैं जो किसी भी क्षमता लीडरबोर्ड पर शीर्ष पांच में नहीं टूटेंगे। वे बस वास्तव में अच्छे प्रॉम्प्ट पर चल रहे हैं।
फाइन-ट्यूनिंग समीकरण को बदलता है
एक फ्रंटियर मॉडल और एक छोटे खुले स्रोत मॉडल के बीच तुलना फाइन-ट्यूनिंग में प्रवेश करने के बाद बहुत अलग दिखती है। आपके विशिष्ट डोमेन डेटा (आपकी शब्दावली, आपके किनारे के मामले, आपके पसंदीदा आउटपुट प्रारूप) पर फाइन-ट्यून किया गया लामा 3.1 8बी मॉडल आपके विशिष्ट कार्य पर जीपीटी-4ओ को पीछे छोड़ सकता है।
यह एक कल्पना नहीं है। स्वास्थ्य सेवा, कानूनी प्रौद्योगिकी और ई-कॉमर्स में कंपनियों ने बार-बार इसका प्रदर्शन किया है।
फाइन-ट्यूनिंग के साथ शुरुआत करने के लिए कहां से:
- खुले स्रोत मॉडल होस्टिंग, डेटासेट और प्रशिक्षण बुनियादी ढांचे के लिए हगिंग फेस
- लोकप्रिय खुले मॉडल पर तेजी से और सस्ते फाइन-ट्यूनिंग रन के लिए टुगेदर एआई
- कस्टम मॉडल को तैनात करने के लिए रेप्लिकेट, अपने स्वयं के जीपीयू बुनियादी ढांचे का प्रबंधन किए बिना
फाइन-ट्यूनिंग के लिए आगे का निवेश की आवश्यकता होती है: डेटा क्यूरेशन, कंप्यूट समय, और मूल्यांकन कार्य। लेकिन उच्च-मात्रा वाले डोमेन-विशिष्ट कार्यों के लिए, अर्थशास्त्र अक्सर इसके पक्ष में काम करते हैं।
सुरक्षा और डेटा निवासी उपेक्षा नहीं हैं
कुछ अनुप्रयोगों को तीसरे पक्ष के एपीआई में डेटा भेजने की अनुमति नहीं है। विचार करें:
- हिप्पा के तहत संचालित स्वास्थ्य सेवा प्लेटफ़ॉर्म
- पीआईआई या विनियमित लेनदेन डेटा को संभालने वाले वित्तीय उपकरण
- सख्त डेटा निवास आवश्यकताओं वाले उद्यम सॉफ़्टवेयर
इन वातावरण में ऐसे प्रतिबंध हैं जिनके चारों ओर कोई फ्रंटियर मॉडल एपीआई काम नहीं कर सकता, क्षमता की परवाह किए बिना। स्व-होस्ट किए गए मॉडल, चाहे ऑन-प्रिमाइसेस हों या एक निजी क्लाउड में, आगे बढ़ने का एकमात्र मार्ग है। इसका अर्थ है लामा 3, मिस्ट्रल या फाई-3 जैसे खुले स्रोत मॉडल अपने स्वयं के बुनियादी ढांचे पर चल रहे हैं। एक फ्रंटियर मॉडल जिसका आप उत्पादन में कानूनी रूप से उपयोग नहीं कर सकते हैं, वह पूरी तरह से सही विकल्प नहीं है।
मूल्यांकन चरण जिसे टीमें छोड़ देती हैं
अधिकांश टीमें मॉडल का चयन करती हैं जो सबसे महंगा है यह मानकर कि यह सबसे अच्छा है बिना इसका परीक्षण किए। जो वे करना चाहिए वह यह है कि वे अपने वास्तविक उपयोग के मामले के प्रतिनिधि इनपुट के 100 से 200 नमूनों के साथ एक मूल्यांकन सेट बनाते हैं और उन्हें वास्तविक स्थितियों में दो या तीन उम्मीदवार मॉडलों के माध्यम से चलाते हैं।
यहाँ एक प्रक्रिया है जो काम करती है:
- 100 से 200 प्रतिनिधि इनपुट के साथ एक मूल्यांकन सेट बनाएं जो अपेक्षित आउटपुट के साथ हैं
- उन्हें दो या तीन उम्मीदवार मॉडलों के माध्यम से वास्तविक स्थितियों में चलाएं
- स्कोर अपने वास्तविक मानदंडों के खिलाफ: सटीकता, प्रारूप अनुरूपता, स्वर, देरी, प्रति कॉल लागत
- डेटा पर निर्णय लें, नहीं गुत फील या लीडरबोर्ड रैंकिंग
ब्रेनट्रस्ट, प्रॉम्प्टफू और वेट्स एंड बायसेस प्रॉम्प्ट्स जैसे टूल्स इस तरह के व्यवस्थित मूल्यांकन को अनुसंधान पृष्ठभूमि के बिना सुलभ बनाते हैं। यह सेट अप करने में कुछ घंटे लगते हैं। पेआफ यह नहीं है कि आप छह महीने तक गलत मॉडल का चयन नहीं करते हैं।
जब फ्रंटियर मॉडल वास्तव में सही कॉल होता है
न्यायसंगत होने के लिए: ऐसे कार्य हैं जहां फ्रंटियर मॉडल वास्तव में अपनी कीमत का सही न्याय करते हैं।
एक फ्रंटियर मॉडल का उपयोग करें जब:
- कार्य जटिल, बहु-चरण तर्क की आवश्यकता होती है जिसमें कोई स्पष्ट टेम्पलेट नहीं होता है
- आउटपुट गुणवत्ता विचलन महंगा है और आयतन अपेक्षाकृत कम है
- आपको व्यापक विश्व ज्ञान या सूक्ष्म निर्णय लेने की आवश्यकता है जिसे प्रॉम्प्ट के चारों ओर नहीं जाया जा सकता है
- आप प्रोटोटाइप कर रहे हैं और अभी तक कार्य सीमाओं को परिभाषित नहीं किया है
एक हल्के मॉडल के साथ चिपके रहें जब:
- कार्य अच्छी तरह से परिभाषित और पुनरावृत्ति है
- गति और लागत मायने रखती है जिस आयतन पर आप चल रहे हैं
- आप प्रॉम्प्ट इंजीनियरिंग या फाइन-ट्यूनिंग में निवेश कर सकते हैं
- डेटा निवास या अनुपालन नियम तीसरे पक्ष के एपीआई को खारिज करते हैं
बिंदु शक्तिशाली मॉडल से बचना नहीं है। बिंदु यह है कि साक्ष्य के साथ जानबूझकर चुनें, नेतृत्व लीडरबोर्ड पर सबसे बड़े नाम को चुनने के बजाय।
सारांश
एक एआई मॉडल का चयन आपके ऐप के लिए एक प्रतिष्ठा प्रतियोगिता की तरह महसूस नहीं करना चाहिए। कागज़ पर सबसे कैपेबल मॉडल हमेशा आपकी समस्या के लिए सही मॉडल नहीं होता है, या आमतौर पर।
मॉडल को कार्य से मेल खाएं। वास्तविक डेटा पर मूल्यांकन चलाएं। देरी, लागत, सुरक्षा आवश्यकताओं और आपकी टीम की प्रॉम्प्ट इंजीनियरिंग या फाइन-ट्यूनिंग की क्षमता को कारक में शामिल करें। सबसे अच्छे एआई उत्पाद निर्णय उन विशिष्टों में निहित हैं, न कि इसमें कि किस कंपनी ने पिछले तिमाही में सबसे चमकदार संख्या प्रकाशित की है।
टीमें जो महान एआई उत्पादों को शिप कर रही हैं उन्हें आवश्यक रूप से सबसे शक्तिशाली मॉडल नहीं चलाना है। वे सबसे उपयुक्त लोगों को चला रहे हैं।
