पुढील‑पिढीतील AI मॉडेल (Next-gen AI models) दोन बॅगांसोबत येतात: एक बेंचमार्कने भरलेली आणि दुसरी आश्वासनांनी.
‑4.6 पण याला अपवाद नाही. हे मॉडेल ताज्या आकडेवारी, दशांशानंतरचे अधिक अंक आणि 'तर्क' (reasoning) याबद्दलच्या नवीन घोषणेसह सादर झाले आहे. मार्केटिंगमध्ये या शब्दाचा खूप वापर केला जातो. हे मशिन इंटेलिजन्सचे 'Organic' आहे—अस्पष्टपणे सद्गुणी, कधीकधी अर्थपूर्ण, बहुतेक वेळा फक्त एक स्टिकर.
चला तर मग हे स्टिकर काढूया. जर तुमचा प्रश्न असेल की “-4.6 काय आहे, त्यात नवीन काय आहे आणि मी ते तर्क आणि एजंटसाठी कसे वापरू शकतो?” तर याचे प्रामाणिक उत्तर आहे: हा एक क्रमिक पण महत्त्वाचा टप्पा आहे. जर तुम्हाला व्यावहारिक कार्यप्रणाली, संरचित टूल वापर आणि एजंट फ्रेमवर्कची काळजी असेल, तर हे तुमच्यासाठी महत्त्वाचे आहे. कारण हे मॉडेल तुम्हाला अनोळखी स्प्रेडशीट दिल्यावर लगेच गडबड करत नाही. जर तुम्हाला फक्त दिखावा हवा असेल, तर तसे अनेक मॉडेल्स आहेत. पण तुम्हाला जर असे मॉडेल हवे असेल जे कामावर टिकून राहील, तर -4.6 हे तुमच्या कामावर अवलंबून रंजक ठरू शकते.
हा एक सखोल अभ्यास/स्पष्टीकरण आहे. यात -4.6 तर्क प्रक्रिया आणि एजंट ऑर्केस्ट्रेशनसाठी कसा उपयुक्त आहे आणि या प्रक्रियेत स्वतःला फसवू नये यासाठी काय करावे, हे सांगितले आहे.
-4.6 नेमके काय आहे (आणि काय नाही)
हे मोठ्या भाषिक मॉडेलचे (large language models) एक कुटुंब आहे. 4.x लाइन मल्टी-टर्न रिझनिंग (multi-turn reasoning), टूल वापर आणि विस्तृत संदर्भ विंडोवर लक्ष केंद्रित करते. -4.6 हे नवीन प्रकाशन आहे, जे तुम्ही फक्त काम करताना बघू शकता. यात सातत्यपूर्ण चेन-ऑफ-थॉट स्केफोल्डिंग (chain-of-thought scaffolding), फंक्शन-कॉलिंगचे उत्तम पालन, लांब प्रॉम्प्टमध्ये (prompts) कमी स्व-विरोधाभास आणि संरचित इनपुटचे (structured inputs) अधिक व्यवस्थित हाताळणी यांचा समावेश आहे. हे काम झटपट डेमोमध्ये (demo) दिसत नाही, पण जेव्हा तुम्ही डेमो करणे थांबवून प्रत्यक्ष काम सुरू करता, तेव्हा दिसून येते.
हे नाही, जादू नाही आणि प्रत्येक दुसऱ्या बुधवारी प्रेस रिलीजमध्ये (press release) सांगितल्याप्रमाणे ते इतर सर्व मॉडेल्सना बदलणार नाही. जर तुम्ही एकदाच काहीतरी सिद्ध होण्याची किंवा थिअरम-लेव्हल अचूकतेची अपेक्षा करत असाल, तर ते शक्य नाही. पण अनेक टूल कॉल्स (tool calls) आणि मोठ्या संदर्भांना हाताळताना होणाऱ्या चुका कमी होण्याची शक्यता नक्कीच आहे.
-4.6 मध्ये नवीन काय आहे (महत्त्वाचे तपशील)
- लांब, अधिक स्थिर संदर्भ: केवळ जास्त टोकन (tokens) नाहीत, तर विभागांमध्ये उत्तम टिकून राहण्याची क्षमता आहे. परिच्छेद तीनमध्ये नमूद केलेले बंधन परिच्छेद बारामध्ये तुम्ही टूल कॉल करतांना विसरण्याची शक्यता कमी आहे.
- अधिक मजबूत फंक्शन कॉलिंग: युक्तिवाद अधिक सातत्याने तयार केले जातात. ला आकार देण्यासाठी कमी 'यॅक-शेव्हिंग' (yak-shaving) आणि कमी चुकीच्या कीज (hallucinated keys). जर तुम्ही एजंट तयार करत असाल, तर तुम्हाला माहीत असेल की बहुतेक मॉडेल्स इथेच अडखळतात.
- स्ट्रक्चर्ड रिझनिंग बायस (Structured Reasoning Bias): तुम्ही -4.6 ला हलक्या 'प्लॅन-देन-ऍक्ट' (plan-then-act) लूपमध्ये ढकलु शकता. हे तत्त्वज्ञांप्रमाणे विचार करण्याचे नाटक करणार नाही, पण एका चांगल्या प्रोजेक्ट मॅनेजरप्रमाणे (project manager) प्रत्येक स्टेपचा मागोवा ठेवेल.
- मल्टी-मॉडल टच (Multi-Modal Touches) (जर तुम्हाला गरज असेल तर): इमेज-अवेअर व्हेरिएंट (image-aware variants) फॉर्म रीडिंग (form reading) आणि पार्सिंगवर (UI parsing) अधिक अंदाजे वागतात. हे आर्ट-टॉयसारखे (art-toy) नाही, तर कंटाळवाणे पण उपयुक्त आहे.
- लेटेंसी/कॉस्ट ट्विक्स (Latency/Cost Tweaks): कमी स्पाइक्स (spikes), अधिक अंदाजे थ्रुपुट (throughput). हे विनामूल्य नाही, पण प्रॉडक्शन डॅशबोर्डमध्ये (production dashboards) पुरेसे महत्त्वाचे आहे.
बेंचमार्क? तुम्हाला नेहमीचे संशयित आढळतील— हे, ते—वर ढकललेले. यात आकडे महत्त्वाचे नाही, तर लोड (load) अंतर्गत सातत्य आणि टूल चेनदरम्यान (tool chains) 'हे काय झाले?' असे क्षण कमी होणे महत्त्वाचे आहे.
-4.6 सह तर्क: इच्छा करणे सोडा, मर्यादा निश्चित करा
मधील 'तर्क' म्हणजे स्टेपनुसार (stepwise) मजकूर पूर्ण करण्याकडे असलेला सांख्यिकीय नमुना (statistical pattern). ते ठीक आहे. पण ते काहीतरी वेगळे आहे असाVirtual Assistant केल्यास, चुकीचे प्रॉम्प्ट (prompts) आणि वाईट सिस्टीम्स (systems) तयार होतात. -4.6 तुम्हाला खालील गोष्टी दिल्यावर अधिक चांगले काम करते:
- चातुर्यापेक्षा बंधने: लक्ष्य स्वरूप, स्वीकृती चाचण्या (acceptance tests) आणि अपयशाच्या शर्ती (failure conditions) स्पष्ट करा. गणिताचा आकार स्पष्ट असल्यास मॉडेल गणित करेल.
- संभाषणापेक्षा विभाजन: समस्यांचे टप्प्यांमध्ये विभाजन करा—पार्स (parse) → योजना (plan) → अंमलबजावणी (execute) → पडताळणी (verify). तुम्ही हे सिस्टीम प्रॉम्प्टमध्ये (system prompt) जोडू शकता किंवा टूल कॉल्ससह (tool calls) स्पष्टपणे करू शकता.
- बाह्य मेमरी (Externalized Memory): मॉडेलला तुमचा डेटाबेस (database) बनवू नका. त्याऐवजी, बाह्य स्क्रॅचपॅड (scratchpad) किंवा वेक्टर स्टोअरमध्ये (vector store) डेटा लिहा आणि वाचा. -4.6 कमी विसरते, पण तरीही ते काही क्षण शुद्धीत असलेला मासा आहे.
- पडताळणी हुक्स (Verification Hooks): व्हेरिफायरसोबत (verifier) दुसरी तपासणी करा—कधीकधी तेच मॉडेल, कधीकधी लहान मॉडेल—चुका पकडते. प्रॉडक्शनमध्ये (production) एक जरी चुकीचे उत्तर वाचवले, तरी ते फायद्याचे ठरते.
टेब्युलर रिझनिंगसाठी (tabular reasoning) येथे एक साधे आणि प्रभावी लूप (loop) आहे:
- स्टेप 1: प्रश्नातील स्कीमा (schema) आणि बंधने काढण्यासाठी -4.6 ला सांगा.
- स्टेप 2: त्याला योजना आणि 'आवश्यक टूल्स' प्रस्तावित करण्यास सांगा.
- स्टेप 3: मॉडेलद्वारे -एन्कोड केलेल्या (JSON-encoded) युक्तिवादांसह (arguments) टूल कॉल्स (, , जे काही असेल ते) कार्यान्वित करा.
- स्टेप 4: टूलचे निकाल परत पाठवा आणि काढलेल्या पंक्तींशी (rows) बांधलेल्या योग्य कारणासह अंतिम उत्तराची मागणी करा.
युक्ती म्हणजे फॅन्सी प्रॉम्प्ट्स (fancy prompts) वापरणे नाही, तर मॉडेलला जिथे नको तिथे improvising (improvise) करू न देणे.
-4.6 सह एजंट: मांजरांची राखण, आता दोरीसकट
एजंट म्हणजे जिथे 'hype' प्रॉडक्ट मॅनेजमेंटसारखे (product management) दिसते. बहुतेक 'autonomous' एजंट हे स्टोअरमध्ये (LEGO store) सोडलेल्या रूमबासारखे (Roomba) असतात—व्यस्त, पण निरुपयोगी. -4.6 स्वतःहून ते बदलत नाही, पण ते खालील गोष्टी नक्की करते:
- अधिक विश्वसनीय टूल करार: जेव्हा तुम्ही get_flights(origin, destination, date) कॉल करण्यास सांगता, तेव्हा जोपर्यंत तुम्ही cabin_class बद्दल विचारत नाही तोपर्यंत ते स्वतःहून काहीही तयार करत नाही. हाच डेमो (demo) आणि रिफंडमधील (refund) फरक आहे.
- उत्तम स्टेप अकाऊंटिंग (Step Accounting): जर तुम्ही त्याला टूल कॉल्सवर (tool calls) थांबण्यास सांगितले किंवा मंजुरी चेकपॉईंटची (approval checkpoint) आवश्यकता घातली, तर ते अधिक वेळा त्याचे पालन करते. आज्ञापालन कमी लेखले जाते.
- सहन करण्यायोग्य लांब-क्षितिज कार्ये (Long-Horizon Tasks): स्पष्ट माइलस्टोन (milestones) आणि मेमरी स्टोअरसह (memory store), ते फॅन-फिक्शनमध्ये (fan-fiction) न जाता अनेक दिवसांचे कार्य करू शकते.
-4.6 एजंटमधील (agents) जिंकण्याची पद्धत 'त्याला मोकळे सोडणे' नाही, तर 'tight loop, short leash, clear rewards' आहे.
एक व्यावहारिक सांगाडा: प्रॉम्प्टपासून (Prompt) पाइपलाइनपर्यंत (Pipeline)
याला तुम्ही काहीही म्हणा—'deliberate reasoning', 'planner-executor'—पाइपलाइन खालीलप्रमाणे दिसते:
- सिस्टीम: तुम्ही एक सावध योजनाकार आहात. योजनेशिवाय तुम्ही टूल्स (tools) वापरणार नाही. तुम्ही स्कीमामध्ये (schema) तयार करणे आवश्यक आहे.
- वापरकर्ता: कार्य (स्पष्ट, मर्यादित, चांगले वि. वाईट उत्तरांच्या उदाहरणांसह).
- सहाय्यक (योजना): मॉडेल स्टेप्सचा (steps) मसुदा तयार करते, टूल्स निवडते आणि गृहितके (assumptions) नमूद करते.
- टूल कॉल्स: निश्चित, टाइप केलेले युक्तिवाद (arguments). स्कीमा त्रुटींवर (schema errors) नकार द्या. प्रत्येक गोष्टीची नोंद ठेवा.
- सहाय्यक (संश्लेषण): मॉडेल टूलच्या (tool) आउटपुटला (outputs) योजनेसह एकत्रित करते आणि अंतिम निकाल देते.
- सत्यापनकर्ता: हलके चेक (check)—कधीकधी फक्त regexes आणि स्वीकृती चाचण्या (acceptance tests)—चूक पकडण्यासाठी.
-4.6 चे योगदान: कमी योजना/अंमलबजावणी विसंगती (mismatches) आणि अधिक सातत्यपूर्ण युक्तिवादांचे आकार. हे आकर्षक नाही, पण उपयुक्त आहे.
प्रॉम्प्टिंग (Prompting) जे तुम्हाला खोटे बोलत नाही
- बुद्धिमान बनण्याचा प्रयत्न करू नका. संरचनेची मागणी करा: 'गृहितकांची (assumptions) यादी करा', 'युनिट रूपांतरण (unit conversions) दर्शवा', 'तुम्ही वापरलेल्या पंक्ती उद्धृत करा'.
- असे नियम वापरा जे कठोर असतील. 'जर तुम्हाला खात्री नसेल, तर स्पष्टीकरण मागा' हे निरुपयोगी आहे, जोपर्यंत तुम्ही 'खात्री नाही' हे परिभाषित करत नाही आणि प्रश्नाची मागणी करत नाही.
- लांब प्रवचनांपेक्षा (sermons) उदाहरण जोड्यांना प्राधान्य द्या. दोन चांगली उदाहरणे दोन पानांच्या 'vibes' पेक्षा चांगली.
- मॉडेलला 'मला माहीत नाही' असे म्हणू द्या. अक्षरशः त्या वाक्यांशाला परवानगी द्या. अन्यथा ते कधीही वापरणार नाही.
-4.6 पूर्वीच्या तुलनेत या कार्यक्रमात अधिक सहजपणे सामील होते. हीच प्रगती आहे: कमी खोटेपणा, अधिक सत्यता.
डेटा, टूल्स आणि फंक्शन कॉलिंगचा (Function Calling) कंटाळवाणा जादू
फंक्शन कॉलिंग म्हणजे जिथे तर्क नाटक करणे थांबवते. -4.6 सह:
- स्कीमा टिकून राहतात: फंक्शन सिग्नेचर (function signature) एकदा शिकवा आणि अनेक टप्प्यांमध्ये पुन्हा वापरा.
- मल्टी-टूल सिक्वेन्स (Multi-Tool Sequences) व्यवस्थित वागतात: योजना → शोध → आणा → सारांश (plan → search → fetch → summarize) आता योजना → सारांश → पुन्हा सारांश (plan → summarize → summarize again) असे होत नाही.
- लवकर अयशस्वी व्हा: जर एखाद्या टूलने (tool) युक्तिवाद नाकारला, तर त्रुटी मॉडेलला परत पाठवा आणि सुधारात्मक वळण (corrective turn) घेण्यास भाग पाडा. शांतपणे दुरुस्त करू नका; मॉडेलला ते करण्यास सांगा.
जर तुम्ही रिसर्च असिस्टंट (research assistants), कस्टमर सपोर्ट बॉट (customer support bots) किंवा डेटा एजंट (data agents) तयार करत असाल, तर प्रत्येक वेळी टूल कॉल्स योग्य मिळवणे हीच खरी जादू आहे. -4.6 कंटाळवाणे काम अधिक चांगल्या प्रकारे करते.
लांब संदर्भ: भटकण्यासाठी अधिक जागा, हरवण्यासाठी कमी सबबी
संदर्भाच्या विंडोज (windows) वाढल्या कारण आम्ही त्यात अधिक पेस्ट करत राहिलो. -4.6 कमी क्रॉस-टॉकसह (cross-talk) लांब संदर्भ हाताळते. तरीही, काही नियम:
- चंक (Chunk) आणि शीर्षक (Title): लहान, स्पष्ट शीर्षके (headers) वापरा. मॉडेल्स परिच्छेदांपेक्षा लेबल्स (labels) अधिक चांगल्या प्रकारे 'लक्षात' ठेवतात.
- पेस्ट करण्यापेक्षा पॉइंटर्स (Pointers): जर पॉइंटर (pointer) आणि रिट्रीव्हल हुक (retrieval hook) पुरेसे असतील, तर परिशिष्ट (appendix) भरू नका.
- जबाबदारीने सारांश: फक्त 'docs म्हणतात' असे न सांगता, मॉडेलला विभाग उद्धृत करण्यास सांगा.
याचा फायदा म्हणजे कमी phantom recollections (phantom recollections) आणि अधिक tethered summaries (tethered summaries).
कोडिंगसाठी -4.6 वापरणे: त्याला बेधुंद होऊ देऊ नका
हे बॉयलरप्लेट (boilerplate) साठी चांगले आहे आणि जर तुम्ही 'diff' नियंत्रित केले तर refactors साठी ठीक आहे. नॉन-ट्रिव्हियल कोडजेनसाठी (non-trivial codegen):
- प्रथम इंटरफेस (Interfaces) निर्दिष्ट करा. प्रकार (types), स्वाक्षऱ्या (signatures), इनपुट/आउटपुट करार.
- अंमलबजावणीपूर्वी युनिट टेस्ट (Unit Tests). मॉडेलला टेस्ट (tests) लिहायला सांगा, नंतर कोड. टेस्ट चालवा. अयशस्वी गोष्टी परत फीड करा.
- लहान बॅचेस (Batches). एका वेळी एक फंक्शन (function). विलीन करा, नंतर पुढे जा.
जर तुम्ही या नियमांचे पालन केले, तर -4.6 अधिक हुशार दिसेल. हे ढोंग नाही; तुम्ही स्वतःला रुळावरून घसरण्याची शक्यता कमी करत आहात.
तर्कदोष -4.6 कमी करते (पण पूर्णपणे नाही)
- सुरुवातीच्या अंदाजांवर आधारित राहणे: निर्णय घेण्यापूर्वी त्याला पर्याय सूचीबद्ध करण्यास सांगा. तुम्हाला 'पहिली कल्पना सर्वोत्तम' असे कमी उत्तरे दिसतील.
- अति-सारांश: शोधण्यायोग्य अवतरणे (traceable quotes) किंवा row आवश्यक आहेत. अन्यथा ते स्वतःच्या सारांशाचे भाषांतर करते.
- योजना-अंमलबजावणी विचलन (Planning-Execution Drift): योजनेला करार बनवा. जर अंतिम उत्तर विचलित झाले, तर त्याला कारण स्पष्ट करण्यास सांगा.
- टूल हल्लुसिनेशन (Tool Hallucination): एक रजिस्ट्री (registry) ठेवा आणि अज्ञात टूल्स नाकारा. मॉडेल कमी शोध लावेल—पण ध्येय शून्य असले पाहिजे.
-4.6 चे मूल्यांकन: बेंचमार्क ज्यावर तुम्ही विश्वास ठेवू शकता (तुमचे)
सार्वजनिक लीडरबोर्ड (leaderboards) रेस्टॉरंट Stars प्रमाणे उपयुक्त आहेत: चांगले सिग्नल, पण तुमची चव नाही. तुमचे बेंचमार्क खालीलप्रमाणे असले पाहिजेत:
- कार्य-बद्ध: 100-200 खरे प्रॉम्प्ट (prompts) प्रॉडक्शनमधून (production), cherry-picked (cherry-picked) केलेले नसावेत.
- स्वीकृती चाचण्यांसह स्कोअर (Scored): Regexes, कॅल्क्युलेटर, स्कीमा व्हॅलिडेटर (schema validators). माणसे बारकावे ओळखतात; मशीन (machine) मूर्ख गोष्टी पकडतात.
- खर्चिक: अचूकतेनुसार नाही, तर प्रति अचूक उत्तराप्रमाणे डॉलर मोजा.
- लेटेंसी-जागरूक: P50 पेक्षा P95 अधिक महत्त्वाचे आहे.
जेव्हा कार्यभार टूल-हेवी (tool-heavy) आणि मल्टी-स्टेप (multi-step) असतो, तेव्हा -4.6 'प्रति अचूक उत्तराप्रमाणे खर्च' यावर चांगले रेटिंग (rating) देते. जर तुमचे काम शून्य संरचनेतील कच्चे गद्य (raw prose) असेल, तर तुम्हाला इतर मोठ्या नावांमध्ये समानता आढळू शकते.
एजंटसाठी -4.6 कसे वापरावे (एक प्लेबुक जे ढोंग करत नाही)
- टूल्सला (tools) इच्छा नसून प्रमाणे परिभाषित करा: इनपुट प्रकार, त्रुटी कोड, उदाहरणे.
- पुनरावलोकन गेट्स (Review Gates) लागू करा: धोकादायक कृतींसाठी (ईमेल, ऑर्डर), मानवी-मंजुरीची (human-approval) स्टेप (step) आवश्यक आहे, ज्यात एकाच स्क्रीनवर फरक दिसेल.
- मेमरी (Memory) बाह्य ठेवा: प्रोजेक्ट नोट्स (project notes), स्टेट (state), डॉक्स (docs)—ते साठवा. मॉडेल वाचते आणि लिहिते; ते ओझे उचलत नाही.
- प्रत्येक गोष्टीचे विश्लेषण करा: टोकन, टूल युक्तिवाद, परिणाम लॉग करा. जर तुम्ही तपासू शकत नसाल, तर तुम्ही त्यात सुधारणा करू शकत नाही.
- हेतूने पुन्हा प्रयत्न करा: कठोर नियमांसह एक सुधारात्मक पास (corrective pass) Allow करा. जर ते अयशस्वी झाले, तर बंद करा.
-4.6 तुम्हाला चांगली सरासरी देते. तरीही तुम्हाला नियम आणि स्कोअरबोर्डची (scoreboard) आवश्यकता आहे.
सुरक्षा, गोपनीयता आणि चाव्या सोपवण्याचा मोह
- fencing: मॉडेल पाहण्यापूर्वी ते मास्क (mask) करा. रहस्ये (secrets) जपण्यासाठी प्रॉम्प्टवर (prompt) विश्वास ठेवू नका.
- टूल सँडबॉक्सिंग (Tool Sandboxing): फाइल सिस्टीम (file system) आणि नेटवर्क कॉल्स (network calls) केवळ व्हाइटलिस्टेड डोमेन (whitelisted domains) आणि पाथ्सपर्यंत (paths) मर्यादित असावेत.
- प्रॉम्प्ट इंजेक्शन (Prompt Injection): सर्व retrieved (retrieved) मजकूर untrusted (untrusted) म्हणून हाताळा. Sanitize करा आणि टूल कॉल काय करू शकते यावर मर्यादा घाला.
- ऑडिट ट्रेल्स (Audit Trails): प्रॉम्प्ट, टूल कॉल्स, आउटपुटचा (outputs) संपूर्ण transcript (transcript) ठेवा. भविष्यात तुम्हाला त्याचे महत्त्व कळेल.
-4.6 नियम तोडण्याचा 'निर्णय' घेणार नाही—पण जर तुम्ही त्याला परवानगी दिली, तर ते आनंदाने विषारी सूचनांचे पालन करेल.
Sider.AI बद्दल एक छोटासा शब्द (कारण ते येथे खरोखरच मदत करते)
Sider.AI खरोखरच काम करते—किमान जेव्हा तुम्ही ते कशासाठी चांगले आहे त्यासाठी वापरता, जे मार्केटिंग म्हणते त्यापेक्षा थोडे वेगळे आहे. जर तुम्ही -4.6 ला तर्क किंवा एजंट वर्कफ्लोमध्ये (agent workflow) वापरण्याचे ध्येय ठेवले असेल, तर Sider ची ताकद आकर्षक नसलेल्या गोष्टींमध्ये आहे: प्रॉम्प्ट स्केफोल्डिंग (prompt scaffolding) जे टिकून राहते, संरचित टूल वायरिंग (structured tool wiring) आणि व्यवस्थित iteration loops (iteration loops), जिथे तुम्ही काय बिघडले आणि का ते पाहू शकता. तुम्हाला समारंभाची गरज नाही; तुम्हाला रन्स (runs), Diff (Diffs) आणि गार्डरेल्सची (guardrails) गरज आहे. Sider तुम्हाला ते कमी दिखाव्यासह देते. -4.6 सोबत जोडून तुम्हाला कमी रहस्यमय अपयश आणि अधिक repeated विन्स (repeated wins) मिळतात. अंमलबजावणी नोट्स: लहान लीव्हर्स (Levers), मोठे फरक
- तापमान: टूल प्लॅनिंगसाठी (0.0-0.2) कमी आणि कल्पनेसाठी (0.6-0.8) जास्त. शक्य असल्यास एकाच कॉलमध्ये योजना आणि गद्य (prose) मिक्स (mix) करू नका.
- कमाल टोकन: इंटरमीडिएट कॉल्सवर (intermediate calls) आक्रमकपणे मर्यादा घाला; संश्लेषणासाठी (synthesis) बजेट राखून ठेवा.
- स्टॉप सिक्वेन्स (Stop Sequences): आउटपुटला (outputs) बांधण्यासाठी त्यांचा वापर करा. एकदा ब्रॅकेट बंद झाल्यावर मॉडेलने गप्प बसावे अशी तुमची इच्छा आहे.
- स्व-समीक्षा पास: एक लहान, स्वतंत्र प्रॉम्प्ट—'या उत्तरामध्ये तीन कोणत्या प्रकारे चूक असू शकतात'—सहज मिळणाऱ्या चुका पकडते.
हे 'हॅक्स' नाहीत. ते मॉडेलला predictable बनवत आहेत.
-4.6 (किंवा कोणतेही मोठे मॉडेल) कधी वापरू नये
- पडताळणीशिवाय अचूक, प्रतीकात्मक गणित: वास्तविक solver वर ऑफलोड (offload) करा.
- -हेवी (PII-Heavy) कार्यभार (workloads) जे तुम्ही मास्क (mask) करू शकत नाही: करू नका.
- निश्चित पार्सर (parsers) असलेली कार्ये: जर regex (regex) करत असेल, तर regex वापरा.
- समीक्षेशिवाय (review) शून्य-सहिष्णुता डोमेन (zero-tolerance domains): compliance letters (compliance letters) किंवा वैद्यकीय सल्ल्याचा विचार करा. loop मध्ये माणूस ठेवा.
कोणतेही मॉडेल (model) सार्वत्रिक हातोडा नाही. -4.6 हे एजंट पाइपलाइनसाठी (agent pipelines) एक solid wrench (solid wrench) आहे, प्रत्येक गोष्टीसाठी sledgehammer (sledgehammer) नाही.
-4.6 एजंटसाठी (agents) एक लहान, क्रूरपणे प्रामाणिक सेटअप
- परिभाषित करा: tools = {search, fetch_doc, extract_table, run_sql, send_email(draft_only)}
- प्लॅन प्रॉम्प्ट: 'स्टेप्ससह (steps) परत करा, प्रत्येक स्टेप एकतर , (name,args), किंवा असावी. कमाल 6 स्टेप्स'.
- गार्ड (Guard): स्कीमाला (schema) जुळत नसलेले आउटपुट नाकारा. त्रुटी संदेशासह पुन्हा प्रयत्न करण्यास भाग पाडा.
- सत्यापित करा: करण्यापूर्वी, एक चेकलिस्ट (checklist) आवश्यक आहे: cited स्रोत (sources), stated गृहितके (assumptions), noted धोके.
- मानवी गेट (Human Gate): केवळ send_email ला 'Y/N' मंजुरी ध्वजासह (approval flag) executable (executable) बनवा.
शिस्तीच्या पाच ओळी तुम्हाला घटनेच्या पन्नास ओळी वाचवतील.
-4.6 वि. क्षेत्र: हे कुठे अधिक चांगले वाटते
- टूल चेन्स (Tool Chains): कमी malformed युक्तिवाद; प्रति कॉल उच्च यश.
- लांब डॉक्स (Docs): स्पष्ट विभाग सह अधिक सुसंगत क्रॉस-रेफरन्स (cross-references).
- Leash वरील एजंट (Agents): स्टेप कॅप्स (step caps) आणि मंजुरी स्टेप्सचे (approval steps) अधिक चांगले पालन.
- खर्च/लेटेंसी: प्रार्थनेच्या मेणबत्तीशिवाय अंदाजपत्रक (budget) तयार करण्यासाठी पुरेसे predictable.
जर तुमच्या ॲपचे मूल्य 90% 'टूल्स योग्यरित्या कॉल करणे' असेल, तर तुम्हाला फरक जाणवेल. जर ते 90% 'एक सुंदर परिच्छेद लिहिणे' असेल, तर तुम्हाला कदाचित नाही जाणवणार.
The Dialectical Bit: 'तर्क' हा योग्य शब्द आहे का?
शायद नाही. पण आपण वापरत असलेला शब्द आपल्याला आवश्यक असलेला वर्तन बदलत नाही. आपल्याला अशा सिस्टीम्स हव्या आहेत ज्या:
- समस्यांचे विभाजन करू शकतील.
- योग्य युक्तिवादांसह योग्य टूल्स कॉल करू शकतील.
- त्यांच्या कामाची तपासणी करू शकतील.
- अनिश्चितता मान्य करू शकतील.
-4.6 त्या दिशेने एक पाऊल पुढे टाकते. नाट्यमय नाही. Headline-worthy नाही. प्रश्न आणि उत्तरांमधील कमी चुकीच्या वळणांच्या जवळ आहे, ज्याची आपल्याला खरोखर काळजी आहे.
निष्कर्ष: कंटाळवाणे भविष्य जिंकते
चे रोमांचक भविष्य fireworks नाही—load-bearing predictability आहे. -4.6 त्या दिशेने एक पाऊल आहे: steadier फंक्शन कॉल्स (function calls), calmer लांब-संदर्भ वर्तन, थोडे कमी make-believe. तुम्ही त्यासह build करू शकता. स्पष्ट करार, बाह्य मेमरी आणि एक verifier सह wrap करा, आणि ते दिसते त्यापेक्षा अधिक हुशार दिसेल—कारण तुम्ही component पेक्षा सिस्टीम अधिक हुशार बनवली आहे. हे अभियांत्रिकी (engineering) आहे. आणि हाच भाग scale करतो.
जर तुम्ही चमत्कारासाठी आला असाल, तर तुम्ही निराश व्हाल. जर तुम्ही तिकीट कमी करण्यासाठी, retries कमी करण्यासाठी आणि एजंट्सना (agents) 'Dear FIRST_NAME' ईमेल करण्यापासून वाचवण्यासाठी आला असाल, तर तुम्ही आनंदी व्हाल. कंटाळवाणे जिंकते. -4.6 तुम्हाला तिथे पोहोचण्यास मदत करते.
FAQ
Q1: -4.6 मध्ये तर्क work फ्लोसाठी (work फ्लो) नवीन काय आहे?
-4.6 फंक्शन कॉलिंग (function calling) tight करते, लांब संदर्भासह (context) अधिक चांगले वागते आणि कमी विचलन (drift) असलेल्या 'प्लॅन-देन-ऍक्ट' (plan-then-act) प्रॉम्प्ट्सचे (prompts) पालन करते. हे जादू करणार नाही, पण मल्टी-स्टेप (multi-step) तर्क पाइपलाइनमध्ये (pipelines) कमी गोष्टी बिघडवेल.
Q2: मी एजंटसाठी (agents) गोंधळ न करता -4.6 कसे वापरू?
एक लहान leash ठेवा: कठोर टूल स्कीमा (schema), पुनरावलोकन गेट्स (review gates), बाह्य मेमरी (external memory) आणि एक verifier पास (pass). -4.6 स्टेप कॅप्सचा (step caps) आदर करते आणि स्वच्छ युक्तिवाद (arguments) तयार करते, ज्यामुळे एजंट thrash कमी होतो.
Q3: टूल वापरासाठी -4.6 इतर मॉडेलपेक्षा चांगले आहे का?
अनेकदा, हो—विशेषतः जेव्हा तुम्हाला योग्य, repeated फंक्शन कॉल्स (function calls) आणि मल्टी-टूल सिक्वेन्सची (multi-tool sequences) काळजी असते. जर तुमचा कार्यभार (workload) बहुतेक गद्य (prose) असेल, तर तुम्हाला समानता दिसू शकते; जर ते टूल-हेवी (tool-heavy) असेल, तर -4.6 चमकते.
Q4: -4.6 तर्कासाठी सर्वोत्तम प्रॉम्प्ट (prompt) शैली कोणती आहे?
कार्याचे विभाजन करा, आउटपुट स्कीमा (output schema) परिभाषित करा आणि cited गृहितके (assumptions) किंवा row आवश्यक करा. Role-play वगळा; -4.6 flatter पेक्षा स्पष्ट स्टेप्स (steps) आणि गार्डरेल्ससह (guardrails) अधिक चांगले करते.
Q5: -4.6 अजूनही कुठे कमी पडते?
पडताळणीशिवाय प्रतीकात्मक गणित, मास्किंगशिवाय (masking) गोपनीयता-संवेदनशील कार्ये आणि शून्य-सहिष्णुता डोमेन (zero-tolerance domains). हे संरचित तर्क आणि एजंटमध्ये (agents) अधिक मजबूत आहे, निश्चित टूल्सचा (tools) पर्याय नाही.
