प्रत्येक नवीन मॉडेल रिलीजमुळे तोच जुना वाद पुन्हा सुरू होतो. समीक्षक विजेता घोषित करण्यासाठी आणि मागील टियरला मृत ठरवण्यासाठी घाई करतात. GPT-5.6 Luna, Terra आणि Sol सोबत उपलब्ध असल्याने, एक तर्क आपोआप तयार होतो: Luna इतकी स्वस्त आणि सक्षम आहे की ती Terra ला अप्रासंगिक बनवेल. हे चुकीचे आहे. ते महाग देखील आहे. तुमच्या कोडिंग एजंट्ससाठी मॉडेल निवडणे ही सौंदर्याची स्पर्धा, टीमची ओळख किंवा बेंचमार्कची शर्यत नाही. ती एक ऑपरेटिंग पॉलिसी (कार्यपद्धती) आहे. ज्या टीम्स हा फरक समजून घेतील, त्या प्रत्येक विनंतीसाठी सर्वात शक्तिशाली मॉडेल वापरणाऱ्या टीम्सपेक्षा कमी खर्च करतील, वेगाने काम करतील आणि कमी चुका करतील.
तुमचा डिफॉल्ट पर्याय हा योग्य आणि सर्वात स्वस्त साधन असावा
Luna हा 'व्हॅल्यू टियर' आहे, आणि हे केवळ कौतुक नाही. ते मर्यादित, स्पष्ट आणि सोप्या कामांसाठी उत्तम आहे. वर्गीकरण (classification), सारांश लेखन (summarization), कोडमधील छोटे बदल आणि प्राथमिक संशोधन (first-pass research) यांसारख्या कामांचा विचार करा. जेव्हा एखादा एजंट प्रायोरिटी लेबल लावण्यासाठी सपोर्ट तिकीट वाचतो, तेव्हा Luna पुरेसा आहे. जेव्हा तो काही फाइल्समध्ये व्हेरिएबलचे नाव बदलतो किंवा git diff चा एक परिच्छेद सारांश तयार करतो, तेव्हा Luna पुरेसा आहे. ही अशी कामे आहेत ज्यांची व्याप्ती मर्यादित आहे, इनपुट स्पष्ट आहेत आणि आउटपुट वस्तुनिष्ठपणे तपासता येण्यासारखे आहेत.
आर्थिक परिणाम खेळाचे नियम बदलतो. Luna स्वस्त आहे. मोठ्या प्रमाणात वापर करताना, यामुळे ऑटोमेशन हे एक महागडे काम न राहता पायाभूत सुविधा (infrastructure) बनते. तुम्ही टोकन्स मोजणे थांबवता आणि थ्रूपुट (throughput) मोजण्यास सुरुवात करता. जर अतिरिक्त ५% कामामुळे निकालात काही फरक पडत नसेल, तर ८५% कामे करणारे महागडे मॉडेल यापेक्षा ८०% नियमित कामे करणारे स्वस्त मॉडेल अधिक मौल्यवान ठरते. जर Luna दोन सेकंदात युनिट टेस्ट तयार करत असेल आणि Terra पाचपट खर्चात आठ सेकंदात थोडी अधिक चांगली टेस्ट तयार करत असेल, तर हे गणित तेव्हाच लागू होते जेव्हा कोणीतरी प्रत्येक ओळ काळजीपूर्वक तपासत असेल. बहुतेक वेळा, कोणीही तसे करत नाही. मर्यादित कामांसाठी Luna तुमचा डिफॉल्ट पर्याय असावा, कारण बहुतेक कामे मर्यादित स्वरूपाची असतात.
जेव्हा मर्यादा संपतात, तेव्हा पुढील स्तरावर जा (Escalate)
Terra निरुपयोगी नाही. तो तुमचा 'एस्केलेशन टियर' आहे, आणि स्पष्ट मर्यादा नसलेल्या कामांमध्ये तो स्वतःचे महत्त्व सिद्ध करतो. जेव्हा उद्दिष्ट अस्पष्ट असते किंवा कामामध्ये डिप्लॉयमेंट पाथ (deployment paths), क्रॉस-मॉड्यूल बदल किंवा इन्सिडेंट ट्रायज (incident triage) सारख्या जटिल प्रणालींचा समावेश असतो, तेव्हा त्याचा वापर करा. फीचर फ्लॅग्ससह स्टेजिंग, कॅनरी आणि प्रोडक्शन एन्व्हायरनमेंटमधून जाणारा डिप्लॉयमेंट पाथ हा कोणताही सुटसुटीत स्पेसिफिकेशन शीट नसतो. बिलिंग लॉजिकमध्ये बदल करणारा आणि रिपोर्टिंग पाइपलाइनवर परिणाम करणारा रिफॅक्टर (refactor) ही मर्यादित काम नाही. प्रोडक्शनमधील अशी घटना जिथे लॉग्समध्ये API टाइमआउटबद्दल समस्या दिसत आहे, पण मूळ कारण गेल्या तिमाहीतील मायग्रेशन स्क्रिप्टमध्ये आहे, तिथे निर्णयाची (judgment) गरज असते.
Terra तो निर्णय देतो. तो लक्षणे आणि कारणे वेगळी करतो. Luna तात्पुरता उपाय म्हणून 'रिट्राय लूप' (retry loop) पॅच करू शकते. Terra विचारते की तो रिट्राय लूप असणे आवश्यक आहे का, किंवा मूळ टाइमआउट आर्किटेक्चर ही खरी समस्या आहे का. जेव्हा चुकीचा उपाय तात्पुरत्या संथ गतीचे रूपांतर मोठ्या अपयशात (cascading failure) करतो, तेव्हा हा फरक महत्त्वाचा ठरतो. जर एखादे शक्तिशाली मॉडेल एका चुकीच्या प्रोडक्शन मायग्रेशनमुळे इंजिनिअरचा पूर्ण दिवस वाचवत असेल, तर त्याची किंमत योग्य आहे. एक टाळलेला आउटेज (outage) एस्केलेशनच्या खर्चाची अनेक महिने भरपाई करतो.
Sol ही विमा पॉलिसी आहे, दैनंदिन साधन नाही
Sol अशा प्रकरणांसाठी आहे जिथे अतिरिक्त क्षमता उच्च खर्च न्याय्य ठरवते. उच्च-जोखीम असलेल्या रिव्ह्यूसाठी किंवा आर्किटेक्चरल बदलांसाठी याचा वापर करा. ऑथेंटिकेशन फ्लो पुन्हा तयार करणे, डेटाबेस शार्डिंग (database sharding) पुन्हा डिझाइन करणे किंवा पेमेंट गेटवेशी संबंधित पुल रिक्वेस्ट (pull request) मंजूर करणे या दैनंदिन गोष्टी नाहीत. त्या महत्त्वाच्या घटना आहेत. Sol तुमचा डिफॉल्ट पर्याय नसावा. तो तुमचा 'एक्सेप्शन हँडलर' (exception handler) असावा, ज्याला तेव्हा बोलावले जाते जेव्हा अपयशाचा खर्च स्वस्त मॉडेल्ससाठी सहन करण्यापलीकडे असतो.
सर्वोच्च जोखमीच्या श्रेणीसाठी, Sol ला एका 'डिटरमिनिस्टिक व्हेरिफायर' (deterministic verifier) सोबत जोडा. स्कीमा बदल सुचवण्यासाठी किंवा आर्किटेक्चरल ट्रेड-ऑफ्सचा विचार करण्यासाठी Sol चा वापर करा. तांत्रिक तपशील तपासण्यासाठी तुमच्या CI पाइपलाइन, स्टॅटिक अनालिसिस आणि इंटिग्रेशन टेस्ट्सचा वापर करा. मॉडेल अंतर्ज्ञान (intuition) देते, तर व्हेरिफायर खात्री (guarantees) देतो. जेव्हा परिणामांची व्याप्ती (blast radius) सर्वात मोठी असते, तेव्हा हे संयोजन तुमचे संरक्षण करते.
एक राउटर तयार करा, धर्म नाही
खरा निकष कोणता मॉडेल सर्वोत्तम आहे हा नाही. प्रश्न हा आहे की खर्च, लॅटन्सी (latency) आणि ब्लास्ट रेडियस (blast radius) लक्षात घेता कोणते मॉडेल हे काम हाताळले पाहिजे. मॉडेलची निवड ही तुमची ओळख मानणे थांबवा. "आम्ही Terra वापरणारे लोक आहोत" असे म्हणू नका. त्याऐवजी, कामाच्या प्रकारानुसार (task class) मॉडेल निवडा (route करा).
एक साधा क्लासिफायर तयार करा. येणाऱ्या कामांना त्यांच्या blast radius नुसार टॅग केले जातात. कमी blast radius असलेले काम Luna कडे जाते. मध्यम blast radius असलेले काम Terra कडे जाते. जास्त blast radius असलेले काम एका शक्तिशाली मॉडेलकडे आणि सोबतच एका डिटरमिनिस्टिक व्हेरिफायरकडे (deterministic verifier) पाठवले जाते. सुरुवात करण्यासाठी तुम्हाला परिपूर्ण मशीन लर्निंग क्लासिफायरची गरज नाही. काही ह्युरिस्टिक्स (heuristics) देखील पुरेसे आहेत. केवळ अंतर्गत युटिलिटीजना स्पर्श करणारे आणि मर्यादित ओळींच्या (line count) कोड रिव्ह्यू? Luna. डिप्लॉयमेंट पाइपलाइन्स, क्रॉस-सर्व्हिस कॉल्स किंवा अस्पष्ट आवश्यकतांचा उल्लेख असलेल्या तिकिटे? Terra. ग्राहकांचा डेटा, क्रिटिकल पाथ्स किंवा कायदेशीर अनुपालनाला (legal compliance) स्पर्श करणारी कोणतीही गोष्ट? ती Sol कडे पाठवा आणि मानवी किंवा डिटरमिनिस्टिक रिव्ह्यू अनिवार्य करा.
परिणामांना मोजा, मॉडेलच्या नावांना नाही. प्रति कार्य खर्च (cost per task), रीट्राई रेट (retry rate) आणि एस्केप डिफेक्ट्स (escape defects) यांचा मागोवा घ्या. जर Luna ला तुम्ही सोपवलेली कामे करण्यात अपयश येत असेल, तर त्याची मर्यादा (boundary) वाढवा. जर दररोज पुन्हा पुन्हा येणाऱ्या पॅटर्नसाठी Terra गरजेपेक्षा जास्त (overkill) असेल, तर त्याला Luna कडे वर्ग करा आणि तुमचा खर्च (burn) कमी होताना पहा. तुमचे बजेट न बिघडवता ऑटोमेशन वाढवणे हे उद्दिष्ट आहे. Luna मोठ्या प्रमाणात होणारी बॅकग्राउंड कामे हाताळते. Terra अशा क्षणांना हाताळते जिथे निर्णयाची (judgment) गरज असते. Sol अशा अपवादांवर लक्ष ठेवते जे तुमचे संपूर्ण आठवडा बिघडवू शकतात.
जे संघ हे योग्यरित्या करतात, ते त्यांच्या एजंट फ्लीटला (agent fleet) एका सुव्यवस्थित इंजिनिअरिंग ऑर्गनायझेशनप्रमाणे वागवतात. ते प्रत्येक प्रकल्पात आर्किटेक्ट्सची नियुक्ती करत नाहीत आणि इंटर्न्सना कोअर डेटा मॉडेल पुन्हा डिझाइन करायला सांगत नाहीत. ते क्षमता आणि जोखीम यांचा मेळ घालतात. तुमच्या मॉडेल्ससोबतही तेच करा.
मूळ चर्चा वाचा: GPT-5.6 Luna Is The Value Tier. Terra Is Not Useless
GyaanSetu लर्निंग कम्युनिटीमध्ये सामील व्हा: t.me/GyaanSetuAi