AI ॲप्सना संरचित स्वरूपातील निष्पत्ती का आवश्यक असते?
AI ॲपना संरचित प्रतिसाद आवश्यक असतो, कारण सॉफ्टवेअरला साध्या भाषेतला परिच्छेद विश्वासार्हपणे वाचता येत नाही; त्याला प्रत्येक वेळी तीच क्षेत्रे, त्याच नावांनी आणि त्याच प्रकारांत हवी असतात. एक जास्तीचे वाक्य किंवा एखादे नसलेले क्षेत्र तुमच्या ॲपचा पुढचा टप्पा बंद पाडू शकते.
पार्सलवाइज नावाच्या एका काल्पनिक, 12 जणांच्या लॉजिस्टिक्स स्टार्ट-अपची कल्पना करा. तिथली विकासक सना ग्राहकांचे ईमेल वाचून डिलिव्हरी बदलाचा फॉर्म भरणारे साधन तयार करत आहे: ऑर्डर संदर्भ, विनंती केलेली तारीख, नवीन पत्ता आणि ग्राहक परतावा मागत आहे का. एक नेहमीचा ईमेल असा असतो: 'नमस्कार, ऑर्डर PW-88213, मी गुरुवारी घरी नसेन, त्याऐवजी शनिवारी आणता येईल का? किंवा क्र. 14 कडे ठेवा. ते जमत नसेल तर कृपया रद्द करा आणि परतावा द्या.' तिची पहिली आवृत्ती मॉडेलला 'JSON मध्ये उत्तर द्या' असे सांगते. बहुतेक उत्तरे संगणकाला वाचता येतात, पण काहींची सुरुवात 'नक्की, हे घ्या JSON' अशी होते, काहींमध्ये फील्डचे नाव 'requested_date' ऐवजी 'date' असते आणि एका उत्तरात तारीख 'शनिवार' अशी दिलेली असते.
JSON स्कीमा म्हणजे काय आणि तिचा उपयोग का होतो?
JSON स्कीमा म्हणजे तुम्हाला अपेक्षित असलेल्या डेटाचे औपचारिक वर्णन: कोणती क्षेत्रे असतील, कोणती अनिवार्य असतील, प्रत्येकाचा प्रकार काय असेल आणि कोणती मूल्ये मान्य असतील. मॉडेलला स्कीमा दिल्याने 'कृपया JSON मध्ये उत्तर द्या' ही विनंती तुमचा प्रोग्राम तपासू शकेल अशा करारात बदलते.
सनासाठी रचनानियम असे आहेत: order_reference ही आवश्यक मजकूर साखळी आहे; requested_date ही दिनांकाच्या स्वरूपातील आवश्यक मजकूर साखळी आहे, किंवा दिनांक दिलेला नसल्यास null आहे; new_address ही मजकूर साखळी किंवा null आहे; refund_requested हे आवश्यक बूलियन मूल्य आहे; आणि इतर कोणत्याही रकान्यांना परवानगी नाही. शेवटचा नियम मॉडेलला भाष्याचे रकाने जोडण्यापासून रोखतो.
मॉडेलच्या API संरचित आउटपुटसाठी कशी मदत करतात?
प्रमुख मॉडेलच्या API मध्ये विनंतीसोबत JSON रचना देता येते आणि मॉडेलची निष्पत्ती त्या रचनेशी जुळेल असे बंधन घालता येते.
OpenAI
काटेकोर पद्धत सुरू असताना OpenAI चे संरचित प्रतिसाद वैशिष्ट्य दिलेल्या JSON स्कीमाशी जुळणारीच उत्तरे देण्याचे बंधन घालते. त्याच्या दस्तऐवजांत हे वैशिष्ट्य आणि जुनी JSON पद्धत यांतील फरक स्पष्ट केला आहे. जुनी पद्धत फक्त वैध JSON ची खात्री देते, तुमच्या स्कीमाचे पालन होण्याची नाही. त्यामुळे उपलब्ध असेल तेथे संरचित प्रतिसाद वापरण्याची शिफारस केली आहे.
Anthropic
Claude चे API तुम्ही दिलेल्या स्कीमाशी जुळणाऱ्या JSON निष्पत्ती देते. तसेच साधनांच्या व्याख्यांसाठी काटेकोर पर्याय देते, ज्यामुळे साधनाला दिलेली माहिती त्याच्या स्कीमानुसार पडताळली जाते. कोणती स्कीमा वैशिष्ट्ये समर्थित आहेत आणि कोणती वापरल्यास त्रुटी येते, हे त्याच्या दस्तऐवजांमध्ये दिले आहे.
Gemini API प्रतिसादांसाठी JSON स्कीमा स्वीकारते आणि स्कीमामधील ठरावीक कीवर्डना समर्थन देते. त्याच्या दस्तऐवजानुसार आउटपुट हे वाक्यरचनेच्या दृष्टीने योग्य JSON असले, तरी तुमच्या ॲप्लिकेशनमध्ये मूल्यांची पडताळणी करणे आवश्यक आहे.
तरीही पडताळणी आणि पुन्हा प्रयत्न करण्याची गरज का असते?
तरीही पडताळणी आवश्यक असते, कारण स्कीमा डेटाची रचना नियंत्रित करते, त्यातील मूल्ये योग्य आहेत की नाही हे नाही. रचना अगदी योग्य असलेल्या उत्तरातही चुकीची तारीख, बनावट ऑर्डर संदर्भ किंवा ग्राहकाने कधीही न मागितलेल्या परताव्याची खूण असू शकते.
दोन स्तरांवर पडताळणी करा. प्रथम, Python मधील Pydantic किंवा JavaScript मधील Zod यांसारख्या स्कीमा लायब्ररीने रचना तपासा; OpenAI, Anthropic आणि Google या तिघांच्याही दस्तऐवजांतील उदाहरणांत ही पद्धत दाखवली आहे. दुसरे, व्यावसायिक नियम तपासा: ऑर्डरचा संदर्भ अपेक्षित नमुन्याशी जुळतो आणि प्रणालीत अस्तित्वात आहे का, तारीख भविष्यातील आणि वितरणाचा दिवस आहे का आणि पत्ता वितरण क्षेत्रात आहे का? प्रदात्यांनी दस्तऐवजांत नमूद केलेल्या परिस्थितीही हाताळा: नकार, जो तुमच्या स्कीमानुसार असेलच असे नाही, आणि कमाल टोकन मर्यादेमुळे अर्धवट थांबलेले उत्तर, ज्यात अपूर्ण JSON राहते.
पुन्हा प्रयत्न करताना काळजी घ्या. एखादी तपासणी अयशस्वी झाल्यास, नेमकी त्रुटी नमूद करून एकदा पुन्हा प्रयत्न करा, उदाहरणार्थ 'requested_date ही तारीख असली पाहिजे; ईमेलमध्ये शनिवार म्हटले आहे आणि ऑर्डरची तारीख 14 ऑक्टोबर आहे'. जास्तीत जास्त एक किंवा दोन प्रयत्न करा आणि त्यानंतर ईमेल एखाद्या व्यक्तीकडे पाठवा.
कमकुवत आणि विश्वासार्ह संरचित निष्पत्ती कशी असते?
कमकुवत आवृत्ती: सूचनेत म्हटले आहे, 'तपशील काढा आणि JSON मध्ये उत्तर द्या.' जे काही उत्तर येते, ते ॲप वाचते. वरील ईमेलसाठी त्याला order आणि date नावाची क्षेत्रे, तारखेचे मूल्य 'शनिवार' आणि परताव्याचे मूल्य true मिळते, कारण मॉडेलने 'नसेल तर रद्द करा' ही निश्चित विनंती मानली. फॉर्म चुकीचा भरला जातो आणि ग्राहकाला नको असलेला परतावा मिळतो.
भक्कम आवृत्ती: विनंतीमध्ये सनाने तयार केलेली संरचना काटेकोर पद्धतीसह समाविष्ट आहे आणि सूचनेत प्रत्येक माहितीघटक स्पष्ट केला आहे. त्यात 'ग्राहकाने कोणतीही अट न घालता परतावा मागितला असेल तरच refund_requested चे मूल्य true असते' हेही स्पष्ट केले आहे. मॉडेल order_reference चे मूल्य PW-88213, requested_date चे मूल्य पुढील शनिवारची तारीख, new_address चे मूल्य null आणि refund_requested चे मूल्य false असे देते. नेमक्या अशा परिस्थितीसाठी सनाने संरचनेत जोडलेल्या conditional_request या माहितीघटकाचे मूल्य 'शनिवारी किंवा शेजाऱ्याकडे वितरण शक्य नसल्यास परतावा द्या' असे देते. पडताळणीत ऑर्डर अस्तित्वात असल्याची आणि शनिवारी वितरण होत असल्याची खात्री होते. ईमेलमध्ये सशर्त विनंती असल्यामुळे, नियमानुसार अंतिम निर्णयासाठी तो एखाद्या व्यक्तीकडे पाठवला जातो.
संरचित आउटपुटबाबत होणाऱ्या सामान्य चुका कोणत्या?
सर्वात सामान्य चूक म्हणजे वैध JSON म्हणजे योग्य डेटा असे मानणे. इतर चुका: API मध्ये स्कीमाचे पालन सक्तीने करवण्याची सोय असूनही केवळ प्रॉम्प्टमधील सूचनांवर अवलंबून राहणे, वर्णनांशिवाय अस्पष्ट फील्ड नावे वापरणे, खरे उत्तर null असताना एखादे मूल्य देण्याची सक्ती करणे, नकार आणि अर्धवट तुटलेली उत्तरे दुर्लक्षित करणे आणि काय चुकले हे मॉडेलला न सांगता पुन्हा प्रयत्न करणे.
Tosheo.ai च्या अभ्यासक्रम सूचीमध्ये संरचित निष्पत्ती हा विषय कुठे येतो?
संरचित प्रतिसाद हा AI ॲप्स तयार करण्याच्या अभ्यासक्रमातील, AI ॲप्सची निर्मिती या श्रेणीतील कोडविषयक धडा आहे. यात तुम्ही डेटाची रचना ठरवता, API कॉल करता, प्रतिसादांची वैधता तपासता आणि पुन्हा प्रयत्न करण्याची सोय जोडता. कोडसह संपूर्ण प्रात्यक्षिक आवृत्ती नोंदणी केल्यानंतर कोड अभ्यासमार्गात उपलब्ध आहे. प्रत्येक टप्प्यावर गुणांकन निकषांनुसार अभिप्राय मिळतो.
स्रोत आणि व्याप्ती
Google Gemini API दस्तऐवज, संरचित निष्पत्ती आणि पडताळणीविषयी सल्ला (19 October 2026 रोजी तपासले) ↗