एक ग्राहक ऑर्डरवरील पत्ता बदलतो. त्याच संदेशात परताव्याची मागणी, खराब पॅकेजचा उल्लेख आणि ही तिसरी वेळ असल्याचा सूचक इशाराही असतो. त्या संदेशाला उपयुक्त उत्तर देणे हे एक काम. कोणत्या नोंदी बदलायच्या, कोणत्या पथकाने हस्तक्षेप करायचा आणि कोणत्या कृतींसाठी परवानगी हवी हे ठरवणे वेगळे काम.

TypeSafe AIने 15 सप्टेंबर 2026 रोजी लवकर प्रवेशासाठी सादर केलेले Jev हे निर्णय घेण्याच्या अशा टप्प्यांसाठी आहे. ते सॉफ्टवेअरसाठी मर्यादित, संरचित उत्तरे तयार करते. सर्वसाधारण मॉडेलसोबतचा दीर्घ संवाद ॲप्लिकेशनच्या किती भागांसाठी आवश्यक असावा, याचा पुनर्विचार करण्याचे निमंत्रण हे प्रकाशन देते. TypeSafeची प्रकाशन-घोषणा

TypeSafeचे सहसंस्थापक व CEO Diogo Almeida यांची स्वयंच होस्ट केलेली Latent Spaceमधील 21 सप्टेंबरची मुलाखत या युक्तिवादाला सर्वाधिक विस्ताराने मांडते. दोन तास 22 मिनिटांच्या संभाषणाची संपूर्ण इंग्रजी शीर्षके आम्ही तपासली आणि उत्पादनाचे दस्तऐवजीकरण पडताळले. या मुलाखतीचे आणि सार्वजनिक पुराव्याचे हे विश्लेषण आहे; Jevचा स्वतंत्र बेंचमार्क आम्ही घेतलेला नाही. मूळ मुलाखत पाहा

आमच्या वाचनानुसार, Jevचा सर्वांत महत्त्वाचा प्रस्ताव स्वयंचलनाच्या एककाविषयी आहे. संपूर्ण प्रक्रिया जबाबदारीने सोपवण्यापूर्वी कंपनी विद्यमान प्रक्रियेतील मर्यादित निर्णय स्वयंचलित करू शकते. असा निर्णय पुरेसा स्वस्तपणे पुन्हा घेता येत असेल आणि स्पष्टपणे मोजता येत असेल तर प्रत्येक संवाद चॅटमध्ये न बदलता परिचित व्यावसायिक सॉफ्टवेअरला उपयुक्त क्षमता जोडता येऊ शकते.

याचा परिणाम कार्यप्रवाह तयार करणाऱ्यांवरही वापरकर्त्यांइतकाच होईल. कोणत्या कृतींना परवानगी आहे, चूक कशाला म्हणायचे आणि अपवाद कोण हाताळणार हे कोणाला तरी ठरवावे लागेल. या निर्णयांची गुणवत्ता ठरवेल की हा दृष्टिकोन विश्वासार्ह सेवा उभा करतो की केवळ चुका जलद घडवतो.

TypeSafeने प्रत्यक्षात काय सुरू केले

Jevचा दस्तऐवजीकृत इंटरफेस एक स्थिती आणि प्रकार निश्चित केलेल्या प्रश्नांचा संच घेतो. त्याची तीन मूलभूत साधने अशी: ठरावीक पर्यायांतून निवड करणारे Choice; निकष-सूचीच्या आधारे मूल्यांकन करणारे Score; आणि एखाद्या विधानाची शून्य ते एक या प्रमाणात संभाव्यता दर्शवणारे Noul. Choice आणि Score संभाव्यता-वितरण व विश्वास-पातळीचे क्षेत्र परत करतात. Noulमध्ये असे स्वतंत्र विश्वास-पातळीचे क्षेत्र नसते. दिलेली स्थिती वापरून अनेक प्रश्न स्वतंत्रपणे तपासता येतात. TypeSafeचे इंटरफेसविषयक दस्तऐवजीकरण

ग्राहक-सेवा ॲपमध्ये विकासक या साधनांचा वापर करून पत्ता बदलण्याची विनंती रद्द करण्यापासून वेगळी ओळखू शकतो, तातडीचेपण तपासू शकतो आणि संदेशात नुकसानीचा पुरावा आहे का पाहू शकतो. ही काल्पनिक उदाहरणे आहेत; Jev वापरलेल्या तैनातीचे निकाल नव्हेत. उत्तरे मिळाल्यावर काय करायचे हे ॲप्लिकेशन ठरवेल.

अर्थ लावण्याची जबाबदारी आणि अधिकार देण्याची जबाबदारी वेगळी ठेवणे उपयोगाचे आहे. ग्राहकाला परतावा हवा आहे असा निष्कर्ष AI काढू शकते. पण असा निष्कर्ष काढला म्हणून परतावा देण्याची परवानगी मिळू नये. ॲप्लिकेशन ऑर्डर तपासू शकते, परताव्याची मर्यादा लागू करू शकते आणि आवश्यकतेनुसार मंजुरी मागू शकते.

TypeSafe या मॉडेल-प्रकाराला जलद, अंतर्ज्ञानी विचाराशी तुलना करत System One म्हणते. हे नाव अपेक्षित कामाचे वर्णन म्हणून घ्या. त्यातून मानवी विचारक्षमतेची प्रमाणित खात्री मिळत नाही किंवा सोपी आणि कठीण कामे यांच्यात स्पष्ट सीमा असल्याचे ठरत नाही. छोट्या प्रश्नामागेही गुंतागुंतीचा निर्णय असू शकतो—विशेषतः आवश्यक माहितीच नसताना.

अभियांत्रिकीतील बदल: लहान, तपासता येणारे निर्णय

अल्मेडा कामाचे तुकडे करण्याची बाजू मांडतात: मर्यादित व्याप्तीचे प्रश्न विचारा, मग कोडमध्ये उत्तरे एकत्र करा. मुलाखत, 1:03:02

खराब झालेल्या ऑर्डरचे उदाहरण पुन्हा पाहू. तक्रार हाताळण्याची एक सूचना एकाच उत्तरात अनेक निर्णय लपवते. अधिक तपासता येणाऱ्या रचनेत मागितलेली कृती कोणती, ऑर्डर ओळखता येते का आणि उपलब्ध पुरावा नुकसानीच्या दाव्याला आधार देतो का हे स्वतंत्रपणे ठरवता येईल. धोरणाचे नियम या निर्णयांच्या बाहेर ठेवता येतील.

यामुळे अपयश तपासणे सोपे होते. पत्ता-बदलाची विनंती परतावा-पथकाकडे गेल्यास चालक निर्णय तपासता येतो. नुकसानीचे मूल्यांकन चुकीचे असल्यास त्या घटकाची आधीच्या प्रकरणांवर चाचणी करता येते. व्यापक सूचनेचे मॉडेल सातत्याने पालन करेल अशी आशा न धरता स्पष्ट नियम बदलून धोरण दुरुस्त करता येते.

यासाठी किंमत मोजावी लागते. अधिक घटक म्हणजे सांभाळण्यासाठी अधिक इंटरफेस. उत्तर स्पष्ट करणारा संदर्भ प्रश्नांतून चुकून गाळला जाऊ शकतो. वरकरणी स्वतंत्र वाटणारे दोन निर्णय एकाच दिशाभूल करणाऱ्या पुराव्यावर अवलंबून असू शकतात. प्रत्येक भाग स्वतंत्रपणे स्वीकारार्ह असला तरी एकत्र जोडलेल्या कार्यप्रवाहाचा निकाल अमान्य ठरू शकतो.

अनेक प्रश्न एकत्र विचारणे, गुण एकत्र करणे आणि अनिश्चित प्रकरणे पुढील हाताळणीकडे पाठवणे हे TypeSafeच्या दस्तऐवजीकृत नमुन्यांत समाविष्ट आहे. ते रचनेचे पर्याय सांगतात; ग्राहकाची कोणतीही प्रक्रिया देखरेखीशिवाय चालवायला तयार आहे हे सिद्ध करत नाहीत. TypeSafeचे नमुने

कामाचे तुकडे केल्याने निदान आणि निकाल दोन्ही सुधारतात का, ही उपयुक्त चाचणी आहे. कोणता टप्पा चुकला हे समजावून सांगता येणे मौल्यवान आहे. अपयशांची वारंवारता आणि परिणाम कमी करणे हाच व्यावसायिक फायदा.

Pencil diagram: an input document branches into three parallel questions, whose answers enter a rules box before action or review.
AI-generated conceptual illustration by BIG CHANGE. Input → narrow parallel questions → application rules → action or review. The three questions are illustrative; this is not Jev’s internal architecture.

उत्तर वैध असले तरी ते चुकीचे असू शकते

Jev “भासमान उत्तरे बनवू शकत नाही” या प्रकाशनातील दाव्याचा अर्थ मर्यादित घ्यावा. दिलेल्या आउटपुटच्या रचनेशी उत्तर जुळते यापुरती TypeSafeची हमी आहे. निवडलेले उत्तर सत्य आहे हे त्यामुळे ठरत नाही. रचनेची हमी आणि अनुभवाधारित मूल्यमापन वेगळे असल्याचे कंपनीची स्वतःची घोषणा सांगते. प्रकार-सुरक्षिततेचे TypeSafeकडून स्पष्टीकरण

एखाद्या ॲप्लिकेशनला खालील मूल्ये मान्य आहेत, असे समजा damaged, late आणि other. damaged ही निवड पूर्णपणे वैध असू शकते, जरी पॅकेज फक्त उशिरा आलेले असले तरी. चौथी श्रेणी बनवू न शकणारे मॉडेलही चुकीची निवड करू शकते. यादीत खरोखर आवश्यक श्रेणी नसेल तर संरचनाच समस्येचा भाग ठरते.

संरचित आउटपुट ही अभियांत्रिकीतील आधीपासूनची पद्धत आहे. OpenAIने ऑगस्ट 2024मध्ये schema-constrained Structured Outputs सुरू करतानाच परत आलेल्या मूल्यांच्या आत मॉडेल तरीही चुका करू शकते हे स्पष्ट केले होते. म्हणून सर्व संरचित AI आउटपुटचा शोध लावल्याचे श्रेय Jevला देण्याऐवजी, त्याच्या निर्णय-गुणवत्ता, अनिश्चिततेच्या अहवालाची पद्धत, विलंब आणि खर्च यांच्या विशिष्ट संगमाचे मूल्यमापन करावे. OpenAIची मूळ घोषणा आणि मर्यादा

खरेदीदारांसाठी या फरकामुळे मूल्यमापनाची योजना बदलते. सॉफ्टवेअर उत्तर वापरू शकते का, हे schema चाचणी तपासते. उत्तर पुराव्याशी जुळते का, हे तथ्य-चाचणी तपासते. परिणामी कृतीला परवानगी आहे का, हे धोरण-चाचणी विचारते. एक उत्तीर्ण झाली म्हणून बाकींची जागा भरत नाही.

मुलाखतीतील सर्वात महत्त्वाचे आव्हान कॅलिब्रेशनविषयी आहे

1:09 वाजता परिपूर्ण कॅलिब्रेशनचा दावा Almeida नाकारतात आणि मॉडेल चुका करते हे मान्य करतात. मुलाखत, 1:08:50

भाकीत केलेल्या संभाव्यता आणि अनेक भाकितांच्या गटांत दिसलेले प्रत्यक्ष निकाल यांचा मेळ किती आहे, याविषयी कॅलिब्रेशन असते. प्रत्येक उच्च-प्रायिकतेच्या प्रकरणात अचूक नसतानाही मॉडेल अनिश्चिततेबद्दल उपयुक्त इशारा देऊ शकते. TypeSafeच्या प्राथमिक मार्गदर्शकात हा फरक स्पष्टपणे कायम ठेवला आहे. TypeSafeचे कॅलिब्रेशनविषयक स्पष्टीकरण

APIमधील विश्वास-पातळीच्या क्षेत्राबाबत दुसरा फरकही लक्षात घ्यायला हवा. उत्तर-वितरणातून काढलेली आकडेवारी म्हणून TypeSafe त्याचे वर्णन करते. निवडलेले उत्तर बरोबर असण्याच्या स्वतंत्रपणे मोजलेल्या संभाव्यतेशी त्याची अदलाबदल करता येत नाही. काम आणि त्याचे परिणाम लक्षात घेऊन मर्यादा ठरवण्याची शिफारस दस्तऐवजीकरण करते. विश्वास-पातळीबाबतचे TypeSafeचे दस्तऐवजीकरण

या व्यावहारिक चिंता आहेत. लहान इंग्रजी संदेश योग्य हाताळणारे पण अनेक विनंत्या मिसळलेल्या लांब तक्रारींमध्ये अडखळणारे मार्गदर्शक-मॉडेल कल्पना करा. एकूण गुणांकात ती कमकुवत बाजू लपून राहू शकते. त्या कमकुवत गटातील उच्च-विश्वास निर्णयाकडे परिचित गटातील त्याच दर्शवलेल्या आकड्यापेक्षा अधिक काळजीपूर्वक पाहण्याची गरज असू शकते.

म्हणून संघाने अपुरी माहिती, अपरिचित शब्दरचना आणि मुद्दाम गोंधळात टाकणारे इनपुट यांसह अपेक्षित प्रकरणांची चाचणी घ्यावी. श्रेणीनुसार चुका तपासा आणि प्रकरण परीक्षणासाठी पाठवण्याचा खर्च चुकीची कृती करण्याच्या खर्चाशी तुलना करा. प्रात्यक्षिकातून आकडे उचलण्याऐवजी पुराव्यावर आधारलेले कार्यकारी निर्णय म्हणून मर्यादा ठरवल्या जातात.

कॅलिब्रेशनवरील संशोधन Jevच्या खूप आधीपासून आहे. Chuan Guo आणि सहलेखकांच्या 2017च्या प्रसिद्ध संशोधन-पत्राने आधुनिक न्यूरल नेटवर्क्समधील कमी कॅलिब्रेशन आणि ते सुधारण्याच्या पद्धती तपासल्या. त्या संशोधनातून समस्येची पार्श्वभूमी मिळते; TypeSafeच्या मॉडेलची पडताळणी होत नाही. आधुनिक न्यूरल नेटवर्क्सचे कॅलिब्रेशन

सेवा बदलल्यानंतर काय होते याचाही विश्वासार्हतेत समावेश होतो

मुलाखतीत टिकाऊपणापासून निर्धारवाद आणि दृढतेतील फरक, तसेच दीर्घकालीन सहाय्याची सर्वसाधारण हमी नसणे यांवर चर्चा आहे. मुलाखत, 41:24 आणि 49:40

खरेदीसाठी हे वेगवेगळे प्रश्न आहेत. समान इनपुटवरून समान उत्तर मिळते का, हे निर्धारवाद विचारतो. रेकॉर्डचा वेगळा आयडी यांसारख्या असंबंधित बदलामुळे वर्तनात अवाजवी फरक पडतो का, हे दृढता विचारते. मॉडेल तीच चुकीची उत्तरे वारंवार देत निर्धारवादी असू शकते. भोवतालचा कार्यप्रवाह विश्वासार्ह राहूनही ते किंचित बदलणारी उत्तरे देऊ शकते.

यापैकी कोणताही गुणधर्म उत्पादनाच्या जीवनचक्रातील धोका सोडवत नाही. कोणत्या मॉडेल आवृत्तीने निर्णय दिला, ती आवृत्ती उपलब्ध राहणार का आणि पर्यायाचे मूल्यमापन कसे होईल हे व्यवसायाला समजले पाहिजे. पुरवठादाराच्या चाचण्यांत सुधारणा झाली तरी ग्राहकाने काळजीपूर्वक जुळवलेल्या कार्यप्रवाहाचे वर्तन बदलू शकते.

प्रतिनिधिक प्रकरणे जतन करणे, आवृत्त्यांची नोंद ठेवणे आणि परिणामकारक काम स्थलांतरित करण्यापूर्वी पर्यायाची तुलना करणे हा योग्य उपाय आहे. पर्यायी मार्गही हवा: अन्यथा अचूक असलेली निर्णय-सेवा अनुपलब्ध होऊ शकते. ॲप्लिकेशनकडे काम सुरक्षितपणे थांबवण्याची किंवा अन्यत्र पाठवण्याची सोय नसेल, तर प्रत्यक्ष वापरात उपलब्धताही निर्णय-गुणवत्तेचा भाग ठरते.

याच ठिकाणी आकर्षक APIचे रूप कार्यकारी अवलंबित्वात बदलते. मॉडेल वेगवान झाले म्हणून खरेदी, देखरेख आणि स्थलांतराचे नियोजन नाहीसे होत नाही. एकेक कॉल साधा दिसतो म्हणून ते काम दुर्लक्षित करणे मात्र सोपे होते.

वेग आणि किमतीच्या आकड्यांचा संदर्भ महत्त्वाचा

Jevच्या मथळ्यातील कार्यप्रवाह-निकालांत वेग 193.6 पट आणि खर्चात 444.6 पट सुधारणा नमूद आहे. कंपनीने स्वतः तयार केलेल्या कार्यप्रवाहांत ही कमाल टोकाची सुधारणा असल्याचे घोषणेत स्पष्ट केले आहे. संदर्भ-उत्तरे स्वतंत्ररीत्या सत्य-जमिनीवरील वर्गीकरणांवरून नव्हे, तर इतर मॉडेल्सच्या संभाव्यता-अंदाजांवरून घेतली होती. Jevच्या बाजूने झुकणारे छोटे प्रात्यक्षिक असल्याचे कंपनी मान्य करते आणि दीर्घकाळ टिकणारी किंमत अद्याप ठरायची आहे, असेही सांगते. TypeSafeच्या मूल्यमापनावरील अटी

या अटी आकड्यांसोबतच मांडल्या पाहिजेत. संदर्भ-मॉडेलशी सहमती उपयुक्त माहिती देऊ शकते; पण निश्चित झालेल्या ग्राहक-प्रकरणाशी अचूकतेची ती वेगळी मोजणी आहे. विक्रेत्याने बनवलेला कार्यप्रवाह खरेदीदाराला महत्त्वाचा असू शकतो, पण त्याच्या विनंत्यांच्या वितरणाचे प्रतिनिधित्व करेलच असे नाही.

योग्य तुलनेत संपूर्ण काम समाविष्ट हवे: संदर्भ गोळा करणे, निर्णय घेणे, नियम लागू करणे, अपवाद हाताळणे आणि अपयशातून सावरणे. स्वस्त मॉडेल-कॉलमुळे एकूण खर्च जास्त असू शकतो, जर त्यामुळे पुनरावलोककांकडे खूप काम पाठवले गेले. अधिक खर्चिक पुनर्काम टाळत असेल तर मंद कॉलही किफायतशीर ठरू शकतो.

प्रत्यक्ष ॲप्लिकेशन ज्या प्रदेशातून चालते तिथून विलंब मोजायला हवा. सेवेच्या पायाभूत सुविधांजवळील प्रात्यक्षिक दुसरीकडे असलेल्या वापरकर्त्याच्या अनुभवाचे आश्वासन देत नाही. प्रतिसादात्मक प्रणालींनी सरासरीसोबत मंद विनंत्यांचाही तपास करावा; पार्श्वभूमीतील प्रक्रियेत एकूण कामगिरी आणि खर्च अधिक महत्त्वाचे असू शकतात.

Jevचे नाव घेतल्यावर कार्यक्षमता वाढली की वापरही वाढू शकतो ही संकल्पना आठवते. वैयक्तिक व्यवसायासाठी यात अंदाजपत्रकाचा प्रश्न आहे: कोणते नवे निर्णय मूल्यमापन करण्याइतके मोलाचे बनतील आणि कोणते फक्त अनावश्यक मूल्यमापन होण्याइतके स्वस्त? अधिक मॉडेल-कॉल होणे स्वतःहून निकाल नाही.

वेगळे संशोधन-उद्दिष्ट; पुरावा अजून अपूर्ण

अल्मेडा यांचा संशोधनविषयक युक्तिवाद डेटा, कामाची निवड आणि RLCDला प्राधान्य-ऑप्टिमायझेशनवरील त्यांच्या टीकेशी जोडतो. मुलाखत, 7:23 आणि 22:12

RLCDचा पूर्णार्थ Reinforcement Learning for Calibrated Decisions असा आहे. मानवी पसंती आणि पडताळता येणाऱ्या बक्षीस-पद्धतींच्या तुलनेत वापरण्याजोगे निर्णय आणि संभाव्यता शिकवण्याचे उद्दिष्ट असल्याचे TypeSafe सांगते. हे कंपनीचे संशोधन-उद्दिष्टावरील वर्णन आहे. संपूर्ण प्रशिक्षण-पद्धतीची स्वतंत्र पडताळणी म्हणून त्याचा अर्थ घेऊ नये. TypeSafeचे AI प्राथमिक मार्गदर्शक

पद्धतीचे मूल्यमापन सुरू असतानाही व्यापक प्रश्न तपासण्यासारखा आहे: प्रशिक्षणाचे उद्दिष्ट कोणते वर्तन बक्षीस देते? प्रभावी स्पष्टीकरणाला प्राधान्य देणारे मॉडेल वापरायला सोपे वाटू शकते, पण कोड वापरू शकेल अशा स्वरूपात अनिश्चितता दाखवेलच असे नाही. निर्णयांसाठीचा इंटरफेस अनिश्चितता हाताळणे सोपे करू शकतो, तरी त्याचे आउटपुट वास्तवाशी जुळते का हे बाह्य तपासण्यांतून पाहावे लागते.

प्राधान्य-ऑप्टिमायझेशनमुळे संभाव्य आउटपुटची व्याप्ती लोक बक्षीस देतात त्या उत्तरांकडे संकुचित होऊ शकते, अशी चिंताही TypeSafe mode droppingशी जोडते. हे अपयशाच्या शक्यतेचे कंपनीने केलेले स्पष्टीकरण आहे; पसंतीवर प्रशिक्षित प्रत्येक मॉडेल निर्णय घेण्यासाठी निरुपयोगी आहे असा निष्कर्ष नव्हे. प्राधान्य-ऑप्टिमायझेशनवरील TypeSafeची चर्चा

Almeidaची पार्श्वभूमी या युक्तिवादाला विशेष रंजक बनवते. मानवी अभिप्राय वापरून भाषा-मॉडेलना सूचनांचे पालन करायला शिकवण्याचा अभ्यास करणाऱ्या InstructGPT संशोधन-पत्राचे ते सहलेखक आहेत. हा लेखकत्वाचा पडताळता येणारा तपशील आहे; प्रत्येक प्रयोगशाळेचे काय चुकते याबाबतचे व्यापक दावे वेगळे आहेत. InstructGPT संशोधन-पत्र

प्री-ट्रेनिंगवरील खर्च आणि दिशाहीन नव्या प्रयोगशाळांबद्दलची त्यांची टीका उपयुक्त कामे निवडण्याच्या याच युक्तिवादात बसते. मुलाखत, 1:49:32 आणि 2:03:10

खरेदीदाराने या उत्पादनाचा वापर परिभाषित प्रक्रियेसाठी काय करता येईल हे विचारावे, हा संबंधित धडा आहे. संशोधनातील पार्श्वभूमी, संगणकीय खर्च आणि वेगळी मॉडेल-रचना कंपनी एखाद्या उत्पादनापर्यंत कशी पोहोचली ते स्पष्ट करू शकतात. दुसऱ्या व्यवसायात ते वापरण्याचे अर्थशास्त्र सिद्ध होत नाही.

मुलाखतीत Almeida OpenAIमधून बाहेर पडल्याचे, सुरुवातीच्या अवघड स्वीकाराचे आणि विकासकांच्या नेतृत्वाखाली वाढल्याचेही सांगतात. मुलाखत, 1:31:27 आणि 1:56:48

या आठवणी कंपनीची प्राधान्ये समजावतात. त्या लेखापरीक्षण केलेला स्वीकाराचा पुरावा नाहीत. टिकून राहणारी उपयुक्त कामे आणि ती अयशस्वी झाल्यास मिळणारा आधार यांच्या आधारे विकासक-व्यासपीठाचे अखेरीस मूल्यमापन व्हायला हवे. प्रकाशनानंतरचा उत्साह ही चौकशी करण्याची खूण आहे; त्या नोंदींची जागा नव्हे.

नव्या चॅट-खिडकीपेक्षा विद्यमान सॉफ्टवेअरला अधिक फायदा होऊ शकतो

अधिक सक्षम SaaS उत्पादने येतील आणि AI पार्श्वभूमीत जाईल अशी Almeida यांची अपेक्षा आहे. मुलाखत, 1:19:57

सॉफ्टवेअरमध्ये पुढचा टप्पा बदलू शकेल असे उपयुक्त निर्णय आधीपासून घेतले जातात, म्हणून हा तपासण्याजोगा विश्वासार्ह मार्ग आहे. वेळापत्रक ॲप बुकिंगपूर्वी संदिग्ध विनंती ओळखू शकते. माध्यम-संग्रह संशोधकासाठी सामग्री वर्गीकृत करू शकतो. सेवा-डेस्क साधे अद्यतन आणि लक्ष देण्याजोगी तक्रार वेगळी करू शकतो. ही शक्य डिझाइन्स आहेत; Jev प्रत्यक्ष वापरलेल्या तैनातींची नोंद नव्हे.

इंटरफेसमध्ये कदाचित फारसा बदल जाणवणार नाही. कमी चुका, पुनरावृत्तीचे वर्गीकरण घटणे किंवा योग्य व्यक्तीकडे जलद पोहोचणे हे वापरकर्त्यांना दिसेल. कार्यप्रवाह आधीपासून समजणाऱ्या आणि त्यात चांगले निर्णय समाविष्ट करू शकणाऱ्या कंपन्यांना व्यावसायिक फायदा मिळू शकतो.

विद्यमान सॉफ्टवेअर व्यवसायांसमोर तरीही स्पर्धा राहील. तोच निर्णय अनेक विकासकांना घेता येऊ लागल्यास केवळ मॉडेल-कॉलमुळे वेगळेपणा मिळत नाही. भोवतालच्या उत्पादनाने उपयुक्त डेटा-प्रवेश, विचारपूर्वक रचलेला संवाद आणि काम विश्वसनीयपणे पूर्ण करण्याची सोय द्यावी लागेल.

रोजगाराविषयीच्या दाव्यांत अधिक संयम हवा. एका कामाचा प्रयत्न कमी झाल्याने कर्मचारीसंख्या बदलू शकते, सेवेचे प्रमाण वाढू शकते किंवा अपवादांकडे अधिक काम वळू शकते. या परिणामांवर संस्थेची रचना आणि सेवेची मागणी यांचा प्रभाव असतो. मुलाखत किंवा लवकर प्रवेशाचे प्रकाशन किती नोकऱ्या टिकतील, कमी होतील वा निर्माण होतील हे ठरवत नाही.

BIG CHANGEच्या उद्योगविषयक आढाव्यासाठी मोजता येणारी घडामोड म्हणजे निर्णय स्वयंचलनाची आणखी एक पद्धत उपलब्ध होणे. व्यापक स्वीकार, उत्पादकतेतील वाढ आणि कामगार-बाजारावरील परिणाम हे नंतरचे प्रश्न आहेत; त्यांना वेगळ्या पुराव्यांची गरज आहे.

अंध डेटा, प्रत्यक्ष-वेळेतील सॉफ्टवेअर आणि प्रात्यक्षिकांच्या मर्यादा

साठवलेला डेटा, परस्परसंवादी ॲप्लिकेशन्स, पडताळणी आणि संगणक-वापराची प्रात्यक्षिके यांवर मुलाखतीत चर्चा होते. मुलाखत, 1:34:50

प्रत्येक प्रकारासाठी वेगळे मूल्यमापन हवे. संग्रहातील कामाला काही विलंब चालू शकतो; पण निकाल नमुन्याने तपासता यावा आणि मूळ नोंदीपर्यंत मागोवा घेता यावा. प्रत्यक्ष-वेळेतील इंटरफेसला अंदाजे प्रतिसाद हवा. दुसऱ्या मॉडेलचे मूल्यमापन करणाऱ्या तपासणी-साधनाची त्या मॉडेलकडून होणाऱ्या प्रत्यक्ष चुकांवर चाचणी हवी—दोन्ही प्रणालींनी एकच चूक केली अशा प्रकरणांसह.

संगणक वापरताना कृती निवडणे हा प्रणालीचा फक्त एक भाग आहे. इंटरफेसचे अचूक प्रतिनिधित्व, कृती अंमलात आणण्याचा मार्ग आणि अपेक्षित बदल झाला आहे का याची खात्रीही आवश्यक आहे. देखण्या प्रात्यक्षिकातून एखादी कृती-मालिका एकदा घडली हे सिद्ध होऊ शकते; विश्वासार्ह स्वयंचलनासाठी वारंवारच्या चाचण्या आणि व्यत्ययानंतरची पुनर्प्राप्ती आवश्यक आहे.

खेळांनाही हीच सावधगिरी लागू होते. मॉडेलने नियंत्रित केलेले पात्र अधिक समृद्ध स्थितीला प्रतिसाद देऊ शकते, पण कोणत्या कृती शक्य आहेत हे खेळाचे इंजिनच ठरवते. त्यामुळे खेळण्याचा अनुभव सुधारतो का हे प्रतिसादाचा वेग, सातत्य आणि अनुभवाची रचना यांवर अवलंबून असते. प्रत्येक फ्रेममध्ये अंदाज वापरल्याने खेळ आपोआप अधिक रंजक होणार नाही.

यामुळे श्रेणीविषयक चूक टळते: उपयुक्त घटक जे काम करतो त्याचे श्रेय त्याला द्यावे, पण भोवतालच्या मोठ्या ॲप्लिकेशनच्या सर्व क्षमता त्याच्याकडे असल्याचे गृहीत धरू नये.

मुलाखतीत फाइन-ट्युनिंग, दृश्य ओळख आणि मॉडेलचे आणखी आकार या संभाव्यतांवर चर्चा होते. मुलाखत, 1:10:27 आणि 1:26:23

प्रकाशन-योजनेवरील चर्चा तैनातीच्या आराखड्यातील अवलंबित्व बनू नये. सध्या उपलब्ध इंटरफेसभोवती रचना करा, वेगळ्या घटकाने काय पुरवले पाहिजे ते ठरवा आणि नवी क्षमता प्रत्यक्ष उपलब्ध झाल्यावर तिचे मूल्यमापन करा. त्यामुळे भविष्यातील सुधारणांचा फायदा घेता येईल, पण अंदाजाला उत्पादन-वैशिष्ट्य म्हणून मांडावे लागणार नाही.

कोडिंग एजंट काम वेगळ्या प्रकारे विभागू शकतात

एका मॉडेलची सततची फेरी ओलांडण्यासाठी स्वस्त स्थिती-हाताळणी आणि सामायिक संदर्भाची Almeida यांची कल्पना आहे. मुलाखत, 1:40:17 आणि 2:09:29

एका संभाव्य रचनेत, सक्षम कोडिंग मॉडेल बदल विकसित करेल; लहान निर्णय-कॉल संबंधित फाइल्सचे वर्गीकरण करतील; आणि तयार झालेली कामे सर्वसाधारण सॉफ्टवेअर सांभाळेल. वेगळा समीक्षक अंतिम पॅच तपासू शकेल. हा रचनेचा प्रस्ताव आहे; बेंचमार्कवर पडताळलेली शिफारस किंवा Jev आधीचे कोडिंग एजंट बदलते याचा पुरावा नव्हे.

निवडक संदर्भ हा या पद्धतीचा आकर्षक भाग आहे. उपकामासाठी एकच इंटरफेस आणि काही अटी पुरेशा असताना संपूर्ण संभाषण पाठवणे अपव्यय ठरू शकते. स्पष्ट काम-नोंदींमुळे कोणती तथ्ये महत्त्वाची आहेत, कोणता निर्णय झाला आहे आणि कोणते बदल बाकी आहेत हे ओळखणे सोपे जाऊ शकते.

समन्वयाच्या सूचनेला समांतर लेखनाची हमी समजणे हा धोकादायक भाग आहे. दोन एजंटना एकाच फाइलमध्ये लिहायचे आहे असे वाटू शकते. परस्परविरोधी लेखन रोखणाऱ्या सॉफ्टवेअर यंत्रणांची जागा संभाव्यताधारित मॉडेलने घेऊ नये. अंतिम निकाल अधिकार, आवृत्ती-पडताळणी आणि लॉक यांनीच लागू केला पाहिजे.

तसेच, आधीच्या कामाचा स्वस्त शोध स्मृती-व्यवस्थापन सुधारू शकतो; पण सातत्याने शिकणे म्हणून ओळखल्या जाणाऱ्या प्रत्येक समस्येचे उत्तर त्यात नाही. आधीचा प्रयत्न लक्षात ठेवणे, तो का अयशस्वी झाला हे समजणे आणि नव्या परिस्थितीत विश्वासार्हरीत्या जुळवून घेणे या वेगवेगळ्या क्षमता आहेत. खात्रीशीर मूल्यमापनात पूर्ण झालेली कामे, पुन्हा उद्भवलेल्या चुका, संघर्ष आणि मानवी हस्तक्षेप तपासले पाहिजेत; एजंट किंवा कॉलची संख्या मोजणे पुरेसे नाही.

सुरक्षा संपूर्ण प्रणालीतून जाते; नाहीशी होत नाही

मॉडेलने नकार देण्यापेक्षा ॲप्लिकेशन-स्तरीय सुरक्षा नियंत्रणे Almeida यांना अधिक महत्त्वाची वाटतात; त्याचे परिणाम काय असू शकतात, असा प्रश्न swyx विचारतात. मुलाखत, 13:11 आणि 1:42:29

येथे खरा रचनात्मक प्रश्न आहे: देखरेखीशिवाय चालणाऱ्या ॲप्लिकेशनने एखादा अवलंबित घटक नकार देतो, अयशस्वी होतो किंवा अनिश्चित निकाल देतो तेव्हा काय करावे? त्यासाठी स्पष्ट पर्यायी प्रक्रिया हवी. मात्र प्रत्येक संरक्षण कुठे असावे हे या निरीक्षणाने निश्चित होत नाही.

मॉडेल हेतूची कृती योग्य ओळखत असले तरी ॲप्लिकेशनने प्रवेश-परवानग्या लागू केल्याच पाहिजेत. एखादी नोंद हटवण्याची विनंती पूर्णपणे समजली असेल, तरी ती अनधिकृत असू शकते. तांत्रिकदृष्ट्या वैध विनंती ऑपरेटरच्या धोरणाचे उल्लंघनही करू शकते. पुरेसा संदर्भ नसेल तर निर्णय-सेवा या प्रश्नांची जबाबदारीने उत्तरे देऊ शकत नाही; कृतीवरील नियंत्रण ॲप्लिकेशनकडेच राहिले पाहिजे.

अधिक निर्णय सॉफ्टवेअरमध्ये हलवल्याने तैनातीपूर्वी सीमा निश्चित करण्याचे महत्त्व वाढते. कोणता पुरावा हवा, कोणत्या कृती उलटवता येतील आणि निकालाला व्यक्ती आव्हान देऊन दुरुस्त कसा करू शकेल हे संघांनी ठरवावे. मॉडेलशी होणारा अवघड संवाद काढून टाकला म्हणजे संपूर्ण प्रणाली सुरक्षित आहे असा पुरावा मिळत नाही.

मोठा बदल कसा सिद्ध होईल

या प्रकाशनामुळे स्पष्ट प्रयोग करता येतो. दिसून येणारा निकाल असलेली एक मर्यादित प्रक्रिया निवडा. चुका आणि दुरुस्तीसाठी व्यक्तींनी घालवलेला वेळ यांसह ती आज कशी चालते याची नोंद करा. कृती करण्याचा अधिकार देण्यापूर्वी प्रतिनिधिक प्रकरणांवर निर्णयाधारित आवृत्ती तपासा.

हस्तक्षेपाशिवाय योग्यरीत्या पूर्ण झालेल्या प्रकरणांचे प्रमाण, पुनरावलोकनातून सुटलेल्या चुका, लोकांकडे वळवलेले काम आणि प्रति-प्रकरण एकूण खर्च मोजा. निकाल का स्वीकारला हे समीक्षकाला तपासता यावे म्हणून मूळ पुरावा उपलब्ध ठेवा. मॉडेल, धोरण किंवा इनपुटचा गट बदलल्यावर तुलना पुन्हा करा.

या मूल्यमापनातून प्रक्रियेचा फक्त काही भाग स्वयंचलनासाठी तयार आहे असे दिसू शकते. तोही उपयुक्त निकाल आहे. संदिग्ध प्रकरणे अनुभवी कर्मचाऱ्याकडे ठेवून नेहमीचे वर्गीकरण स्वयंचलित करणे फायदेशीर ठरू शकते; त्यासाठी अधिक व्यापक स्वायत्तता द्यावी लागत नाही.

Jevचे प्रकाशन आणि Almeida यांची मुलाखत AI अर्थव्यवस्थेत कसे प्रवेश करते याविषयी महत्त्वाकांक्षी गृहितक मांडतात: पुन्हा पुन्हा घेता येणारे, मर्यादित निर्णय लोक आधीपासून अवलंबून असलेले सॉफ्टवेअर अधिक सक्षम करू शकतात. ही कामे चुका आणि अपवादांसह दीर्घकाळ करणाऱ्या प्रणालींतून पुढील पुरावा मिळायला हवा. तेव्हाच रंजक मॉडेल-रचना वाचकांना प्रत्यक्ष दिसणारा बदल बनेल.