मॉडल रूटिंग अब कोड नहीं, करियर बन रही है

“हमें किस मॉडल को कॉल करना चाहिए?” सुनने में API से जुड़ा सवाल लगता था। संगठनों की बढ़ती संख्या में यह सवाल अब खरीद, प्रदर्शन-अभियांत्रिकी और आर्किटेक्चर से अधिक जुड़ा हुआ है।

यह बदलाव एक सरल विकास के बाद आया है: अब कई मॉडल उपलब्ध हैं, जिन्हें कई प्रदाता पेश करते हैं, और जिनकी खूबियों, कीमतों, विलंबता प्रोफ़ाइल, परिनियोजन विकल्पों और संविदात्मक शर्तों में महत्वपूर्ण अंतर है। Stripe द्वारा OpenRouter का अधिग्रहण करने की घोषित सहमति एक उपयोगी संकेत है। OpenRouter का एकल API 80 से अधिक प्रदाताओं के 400 से अधिक मॉडलों तक पहुंच प्रदान करता है, जिसमें रूटिंग मानदंडों में कार्य की जटिलता, कीमत, गति, विश्वसनीयता, विलंबता, थ्रूपुट और प्रदाता-विशिष्ट लागत शामिल हैं।

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

रूटिंग, इंफ़्रास्ट्रक्चर के रूप में छिपा हुआ नीतिगत निर्णय है

एक भोला राउटर पूछता है: “कौन-सा मॉडल सबसे सस्ता है?” एक उपयोगी राउटर अधिक विशिष्ट सवाल पूछता है: “इस अनुरोध की गुणवत्ता, विलंबता, विश्वसनीयता, गोपनीयता और परिचालन संबंधी आवश्यकताओं को पूरा करने वाला सबसे कम महंगा मॉडल कौन-सा है?”

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

इसीलिए रूटिंग केवल एप्लिकेशन कोड का विषय नहीं, बल्कि आर्किटेक्चर समीक्षाओं का भी हिस्सा है। रूट केवल इनवॉइस से अधिक चीज़ें निर्धारित करता है। यह डेटा-रेज़िडेंसी, आउटेज के संपर्क, ऑब्ज़र्वेबिलिटी, प्रतिक्रियाओं की एकरूपता, टूल-उपयोग के व्यवहार और आगे आवश्यक मानवीय समीक्षा की मात्रा को प्रभावित कर सकता है।

एक गंभीर रूटिंग फ़ंक्शन के पीछे चार अनुशासन

1. खरीद: केवल प्रमुखता से बताई गई टोकन कीमत की नहीं, पूरे सेवा की तुलना करें

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

रूटिंग के ज़िम्मेदार व्यक्ति को ऐसे फ़ील्ड वाली मॉडल-और-प्रदाता सूची बनाए रखनी चाहिए:

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

नतीजा मॉडल नामों की सूची से अधिक तकनीकी सामग्री की सूची जैसा होना चाहिए। कीमतों, नीतियों, मॉडल संस्करणों या व्यावसायिक मात्रा में बदलाव होने पर इसकी समीक्षा की जानी चाहिए।

2. प्रदर्शन-अभियांत्रिकी: लीडरबोर्ड नहीं, कार्य को मापें

सामान्य बेंचमार्क दिशा-निर्धारण में मदद कर सकते हैं, लेकिन रूटिंग के निर्णयों के लिए कार्यभार-विशिष्ट परीक्षण आवश्यक हैं। सार्वजनिक कोडिंग बेंचमार्क पर अच्छा प्रदर्शन करने वाला मॉडल किसी संगठन के आंतरिक रिपॉज़िटरी, नामकरण परंपराओं, टूल स्कीमा या सुरक्षा नियंत्रणों के लिए सर्वोत्तम विकल्प नहीं हो सकता।

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

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

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

3. आर्किटेक्चर: मॉडल का चयन बदलने योग्य बनाएँ

जब मॉडल-विशिष्ट धारणाएँ पूरे एप्लिकेशन में फैल जाती हैं, तो रूटिंग महँगी हो जाती है। एक लचीला डिज़ाइन व्यावसायिक कार्य को प्रदाता कॉल से अलग करता है।

एक आंतरिक क्षमता अनुबंध परिभाषित करें। इसमें यह निर्दिष्ट हो सकता है कि “वर्गीकरण” ऑपरेशन एक निश्चित स्कीमा, कॉन्फिडेंस या एब्स्टेंशन फ़ील्ड, एक मॉडल पहचानकर्ता और एक ट्रेस पहचानकर्ता लौटाता है। “ड्राफ़्ट प्रतिक्रिया” ऑपरेशन में टोन संबंधी सीमाएँ, उद्धरण संबंधी आवश्यकताएँ और अधिकतम लेटेंसी बजट निर्दिष्ट किए जा सकते हैं। इसके बाद प्रदाता एडेप्टर उस अनुबंध को अलग-अलग API में रूपांतरित करते हैं।

प्रॉम्प्ट, स्कीमा, टूल परिभाषाएँ, सुरक्षा नियम और रूट नीतियों को संस्करणित रखें। रिकॉर्ड करें कि प्रत्येक अनुरोध को किस मॉडल स्नैपशॉट और प्रदाता ने पूरा किया। संवेदनशील उपयोगकर्ता सामग्री को अनावश्यक रूप से सुरक्षित रखे बिना, किसी निर्णय को दोहराने के लिए पर्याप्त जानकारी संरक्षित रखें।

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

4. गवर्नेंस: तय करें कि स्वचालित रूप से रूट कब नहीं करना है

कुछ अनुरोध सबसे सस्ते उपलब्ध मॉडल—या किसी भी बाहरी मॉडल—को नहीं भेजे जाने चाहिए। रूटिंग नीति में गोपनीय डेटा, उच्च-प्रभाव वाले निर्णयों, असमर्थित भाषाओं, असामान्य रूप से लंबे संदर्भ या ऐसे कार्यों के लिए बहिष्करण नियम होने चाहिए जिनमें मानवीय अनुमोदन चरण आवश्यक हो।

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

एक व्यावहारिक रूटिंग तालिका

प्रारंभिक नीति सरल और स्पष्ट हो सकती है:

सटीक तालिका संगठन के अनुसार अलग होगी। महत्वपूर्ण बात यह है कि रूटिंग नियम उत्पाद, सुरक्षा, वित्त और इंजीनियरिंग से जुड़े हितधारकों के लिए पढ़ने योग्य होने चाहिए—उन्हें किसी शर्तीय कथन में छिपा हुआ नहीं होना चाहिए।

करियर बनाने वाले लोगों के लिए इसका क्या अर्थ है

इस काम के लिए सबसे मजबूत उम्मीदवार कई प्रकार की दक्षताओं का संयोजन करेंगे। वे क्षमता और प्रदर्शन में गिरावट के बारे में तर्क करने के लिए पर्याप्त मशीन लर्निंग समझेंगे; विलंबता, पुनःप्रयास, दर सीमाओं और विफलता की स्थितियों को संभालने के लिए पर्याप्त सिस्टम इंजीनियरिंग जानेंगे; कुल लागत का मॉडल बनाने के लिए पर्याप्त वित्तीय समझ रखेंगे; और प्रदाता की प्रतिबद्धताओं व प्रतिबंधों का मूल्यांकन करने के लिए पर्याप्त खरीद तथा गवर्नेंस ज्ञान रखेंगे।

वे निर्णय अभिलेख लिखने में भी सहज होंगे। एक उपयोगी अभिलेख बताता है कि कोई रूट क्यों चुना गया, कौन-से प्रमाण उसका समर्थन करते हैं, कौन-से जोखिम बाकी हैं और कौन-सी घटना पुनर्मूल्यांकन शुरू करनी चाहिए। यह नवीनतम मॉडल नाम याद रखने से अधिक मूल्यवान है, क्योंकि मॉडल नाम और कीमतें बदलती रहेंगी।

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

परियोजना क्या सिद्ध करती है, इसके बारे में सटीक रहें। यह सिद्ध नहीं करती कि एक मॉडल सार्वभौमिक रूप से सर्वश्रेष्ठ है। यह सिद्ध करती है कि आप मॉडल-चयन की अस्पष्ट समस्या को मापने योग्य संचालन नीति में बदल सकते हैं।

करियर संकेत

मॉडल रूटिंग रणनीतिक रूप से महत्वपूर्ण होती जा रही है, क्योंकि बुद्धिमत्ता अब एकल स्थिर निर्भरता नहीं रही। यह अलग-अलग समझौतों और बदलती अर्थव्यवस्था वाली सेवाओं का एक पोर्टफोलियो है। जो टीमें इस पोर्टफोलियो को परस्पर बदले जा सकने वाले बुनियादी ढाँचे की तरह देखती हैं, वे लागत घटा सकती हैं, लेकिन वे गुणवत्ता, अनुपालन और विश्वसनीयता से जुड़ी छिपी समस्याएँ भी पैदा कर सकती हैं। जो टीमें इसे स्थायी एकल-मॉडल प्रतिबद्धता की तरह देखती हैं, वे बेहतर विकल्पों से चूक सकती हैं।

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

Tom Whitfield, AI Career Brief के उत्तरदायी मानव संपादक हैं, जो AI के युग में काम करने के लिए कौशल, भूमिकाओं और समझदारी भरे कदमों को कवर करते हैं।