नफा:
- LLM API विनंतीच्या मूलभूत संरचनेचे वर्णन करू शकते (अंतिमबिंदू, मॉडेल, संदेश, max_tokens)
- सिस्टम, वापरकर्ता आणि सहाय्यक भूमिका आणि स्टेटलेस संभाषण इतिहास यातील फरक समजतो
- परत आलेल्या प्रतिसादाचे फील्ड (सामग्री ब्लॉक, थांबा_कारण, वापर) वाचू आणि त्याचा अर्थ लावू शकतो
मागील मॉड्यूल्समध्ये, आम्ही चॅट विंडोमधून कृत्रिम बुद्धिमत्ता वापरली. परंतु जर तुम्हाला तुमच्या स्वतःच्या उत्पादनात, ऑटोमेशनमध्ये किंवा वर्कफ्लोमध्ये AI एम्बेड करायचे असेल, तर चॅट इंटरफेस ते कापणार नाही; आपल्याला मॉडेलशी प्रोग्रामॅटिकरित्या कनेक्ट करणे आवश्यक आहे, म्हणजेच कोड किंवा ऑटोमेशन टूलसह. या पुलाचे नाव API (Application Programming Interface, दोन सॉफ्टवेअरला ठराविक नियमांसह बोलण्याची परवानगी देणारा करार) आहे. जेव्हा तुम्ही हे युनिट पूर्ण कराल, तेव्हा तुम्हाला कळेल की LLM (लार्ज लँग्वेज मॉडेल) API विनंती काय आहे, संदेशाची भूमिका काय आहे आणि प्रतिसाद कसा वाचायचा. हा पाया आहे ज्यावर उर्वरित मॉड्यूल बांधले जाईल.
API कसे कार्य करते?
API मधील मूळ प्रवाह हा आहे: तुम्ही विशिष्ट स्वरूपात विनंती पाठवता; सर्व्हर विशिष्ट स्वरूपात प्रतिसाद देतो. LLM मध्ये, हा सहसा HTTP कॉल असतो (HTTP: वेबवर विनंती-प्रतिसाद घेऊन जाण्यासाठी मानक प्रोटोकॉल) एकाच पत्त्यावर (एंडपॉइंट, सर्व्हरवरील निश्चित पत्ता जो तुमची विनंती हाताळतो). उदाहरणार्थ, मेसेजिंग API मध्ये, सर्व विनंत्या एकाच पत्त्यावर जातात आणि मुख्य भागामध्ये JSON (JavaScript ऑब्जेक्ट नोटेशन — की/मूल्य जोड्यांचा समावेश असलेले मजकूर स्वरूप जे मानव आणि मशीन दोन्ही वाचू शकतात).
विनंतीमध्ये, तुम्ही किमान या तीन गोष्टी नमूद करा:
- मॉडेल: तुम्ही कोणते मॉडेल वापराल (उदा. जलद आणि स्वस्त मॉडेल किंवा शक्तिशाली मॉडेल).
- max_tokens: टोकनची कमाल संख्या (मजकूरावर प्रक्रिया केलेले सर्वात लहान युनिट, ज्यावर पुढील युनिटमध्ये तपशीलवार प्रक्रिया केली जाईल) मॉडेल तयार करू शकते; म्हणजे आउटपुट मर्यादा.
- संदेश: संभाषण तयार करणाऱ्या संदेशांची सूची.
स्टेप बाय स्टेप: विनंती कशी सेट करावी
- एंडपॉइंट आणि क्रेडेन्शियल तयार करा. तुम्ही तुमची API की (तुमची ओळख सिद्ध करणारी गुप्त स्ट्रिंग) हेडरमधील विनंतीमध्ये जोडता. तुम्ही कोडमध्ये की कधीही एम्बेड करत नाही; आम्ही युनिट 9 मध्ये सुरक्षित स्टोरेज कव्हर करू.
- मॉडेल आणि आउटपुट मर्यादा निवडा. लाइटवेट मॉडेल + साध्या कार्यासाठी लहान कमाल_टोकन्स; शक्तिशाली मॉडेल + जटिल कार्यासाठी मोठी मर्यादा.
- संदेश सूची सेट करा. List the system instruction, user message, and past rounds (if any).
- विनंती पाठवा आणि प्रतिसादाचे विश्लेषण करा. परत आलेल्या JSON कडील मजकूर सामग्री वाचा, कारण थांबवा आणि टोकन वापर.
संदेश भूमिका: सिस्टम, वापरकर्ता, सहाय्यक
संभाषणात क्रमाने मांडलेले संदेश असतात आणि प्रत्येक संदेशाची भूमिका असते. मॉडेल त्या मजकुराशी कसे वागते हे भूमिका ठरवते.
भूमिका
कोण लिहितो
उद्देश
प्रणाली
विकसक/ऑपरेटर
कायमस्वरूपी सूचना, व्यक्तिमत्व आणि नियम जे संपूर्ण संभाषणात लागू होतात
वापरकर्ता
अंतिम वापरकर्ता
वापरकर्त्याचा वर्तमान प्रश्न किंवा इनपुट
सहाय्यक
मॉडेल
मॉडेलने दिलेला प्रतिसाद (आणि मागील प्रतिसाद)
बहुतेक प्रदात्यांमध्ये सिस्टम भूमिका विनंती मुख्य भागामध्ये स्वतंत्र सिस्टम फील्ड म्हणून उपलब्ध आहे; वापरकर्ता आणि सहाय्यक अनुक्रमे संदेश सूचीमध्ये सूचीबद्ध आहेत. Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.
{ "मॉडेल": "claude-opus-4-8", "max_tokens": 1024, "system": "तुम्ही कॉर्पोरेट सपोर्ट असिस्टंट आहात. एक छोटा, औपचारिक आणि सत्यापित प्रतिसाद द्या. तुम्हाला खात्री नसलेली माहिती तयार करू नका.", "messages": [ { "role": "user", "मी प्रक्रिया सुरू करू?" } ]}
भाषण हे स्टेटलेस आहे
येथे सर्वात सामान्य गैरसमज आहे: LLM API कॉल स्टेटलेस आहेत — सर्व्हर दोन विनंत्यांमध्ये कोणतीही मेमरी ठेवत नाही. मॉडेलला तुमची मागील विनंती आठवत नाही. तुम्ही बहु-राउंड चॅट सेट करत असल्यास, तुम्हाला प्रत्येक नवीन विनंतीसह मागील फेऱ्या पुन्हा पाठवाव्या लागतील. मॉडेलच्या "मेमरी" मध्ये तुम्ही पाठवलेल्या संदेशांची सूची असते.
{ "मॉडेल": "क्लॉड-ऑपस-4-8", "max_tokens": 512, "संदेश": [ { "भूमिका": "वापरकर्ता", "सामग्री": "हॅलो, माझे नाव डेनिज आहे." }, { "role": "assistant", "content": "Hello Deniz, मी तुम्हाला कशी मदत करू?" }, { "role": "user", "content": "मी फक्त माझे नाव सांगितले, तुला आठवते का?" } ]}
तिसऱ्या संदेशाचे योग्य उत्तर देणे हे तुम्ही मागील दोन्ही संदेश पाठविण्यावर अवलंबून आहे. जर तुम्ही ते पाठवले नाही, तर मॉडेलला "समुद्र" कळणार नाही आणि ते चुकीचे उत्तर देईल. याचा थेट खर्चावरही परिणाम होतो: संभाषण जितके मोठे असेल तितकी मोठी यादी, प्रत्येक विनंती अधिक टोकन वापरते.
टीप: दीर्घ संभाषणांमध्ये, संपूर्ण इतिहास पाठविण्याऐवजी जुन्या फेऱ्या (सारांश + शेवटच्या काही फेऱ्या) सारांशित करणे आणि हलवणे खर्च कमी करते आणि संदर्भ विंडो संरक्षित करते. आम्ही हे युनिट 6 आणि 11 मध्ये सखोल करू.
उत्तर वाचा
जेव्हा मॉडेल प्रतिसाद देतो, तेव्हा तुम्हाला एक संरचित ऑब्जेक्ट प्राप्त होतो, साधा मजकूर नाही. ठराविक क्षेत्रे:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "assistant", "content": [ { "type": "text", "text": "रिटर्न सुरू करण्यासाठी, तुमच्या खात्यातील 'माझ्या ऑर्डर्स' पेजवर जा..." } ], "stop_reason:" {stop_reason:" "इनपुट_टोकन्स": ४७, "आउटपुट_टोकन्स": ८८ }}
- सामग्री: प्रतिसाद स्वतः; ही सामग्री ब्लॉक्सची सूची आहे. मजकूर ब्लॉकचे मजकूर फील्ड हे वास्तविक उत्तर आहे.
- stop_reason: मॉडेल का थांबले. end_turn = नैसर्गिक अंत; max_tokens = आउटपुट मर्यादेवर अडकले (प्रतिसाद अपूर्ण असू शकतो); refusal = सुरक्षिततेच्या कारणास्तव नकार दिला. तुमचा कोड नेहमी आधी stop_reason पहा.
- वापर: इनपुट आणि आउटपुट टोकन क्रमांक. हा खर्च आणि मर्यादा ट्रॅकिंगचा आधार आहे.
लक्ष द्या: stop_reason max_tokens असल्यास, प्रतिसाद पूर्ण होणार नाही. यास "यशस्वी प्रतिसाद" मानणे आणि वापरकर्त्याला अर्धा मजकूर दाखवणे ही उत्पादनातील सर्वात सामान्य चुकांपैकी एक आहे. एकतर कमाल_टोकन्स वाढवा किंवा स्ट्रीमिंग वापरा.
कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट
दोन भिन्न सिस्टम प्रॉम्प्टसह समान कार्य:
# कमजोर तुम्ही सहाय्यक आहात. प्रश्नांची उत्तरे द्या.
# स्ट्राँग तुम्ही कॉर्पोरेट सपोर्ट असिस्टंट आहात. नियम:- प्रदान केलेल्या पॉलिसी दस्तऐवजातील माहितीवर पूर्णपणे विसंबून राहा; दस्तऐवजात नसल्यास, "माझ्याकडे ही माहिती नाही, मी ती संबंधित युनिटकडे पाठवत आहे" असे म्हणा. - उत्तरे 3 वाक्यांपेक्षा जास्त नसावी, औपचारिक आणि स्पष्ट असावीत. - वैयक्तिक डेटा (TC आयडी क्रमांक, कार्ड क्रमांक) विचारू नका आणि पुनरावृत्ती करू नका. - जेव्हा तुम्हाला खात्री नसते तेव्हा अंदाज लावू नका.
शक्तिशाली आवृत्ती; हे स्कोप, फॉर्म, सुरक्षितता मार्जिन आणि अनिश्चिततेतील वर्तन परिभाषित करते. मॉडेल आउटपुटची सुसंगतता थेट या स्पष्टतेतून येते.
तीन मिनी केसेस
केस 1 - सपोर्ट बॉट (स्टेटलेस ट्रॅप). ई-कॉमर्स टीमने बॉट थेट घेतला; जेव्हा वापरकर्त्याने "मागील ऑर्डर रद्द करा" असे म्हटले, तेव्हा बॉट ऑर्डर क्रमांक "विसरला". कारण: ते प्रत्येक विनंती फक्त शेवटचा संदेश पाठवत होते. उपाय: त्यांनी शेवटच्या 6 फेऱ्या संदेश सूचीमध्ये जोडल्या. परिणाम: संदर्भ जतन केले गेले, परंतु प्रति विनंती इनपुट 40 टोकन्सवरून ~600 टोकनपर्यंत वाढले — आम्ही युनिट 2 मध्ये खर्चाचा धडा कव्हर करू.
केस 2 - अपूर्ण कराराचा सारांश. कायदेशीर संघाने 10-पानांचे करार केले होते; max_tokens: 300 कमी राहिले, सारांश वाक्याच्या मध्यभागी कापत होते. stop_reason प्रत्येक वेळी max_tokens होते पण कोणी दिसत नव्हते. max_tokens 1500 पर्यंत वाढवले आणि stop_reason चेक जोडले; कापलेला सारांश दर 18% वरून 0% पर्यंत कमी झाला.
केस 3 - मिक्सिंग भूमिका. एक मार्केटिंग टीम सिस्टम रिकामी ठेवून सर्व सूचना वापरकर्त्याच्या संदेशात लिहीत होती. जेव्हा वापरकर्ता इनपुट सूचनेमध्ये मिसळला जातो, तेव्हा मॉडेल कधीकधी "मागील नियम विसरा" या वापरकर्त्याच्या आदेशाचे पालन करते. त्यांनी कायमस्वरूपी नियम व्यवस्थेत हलवले; वापरकर्ता इनपुटला सूचनांपासून वेगळे केल्याने, नियमांचे उल्लंघन लक्षणीयरीत्या कमी झाले.
सामान्य चुका
- भूतकाळ पाठविण्यास विसरणे: मॉडेल "आठवत नाही" असे मानले जाते; तर ते राज्यविहीन आहे. तुम्ही संदर्भ घेऊन जाता.
- `stop_reason` पाहत नाही: max_tokens सह थांबलेला प्रतिसाद पूर्ण मानला जातो.
- `वापरकर्ता` मध्ये सूचना एम्बेड करणे: सिस्टीममध्ये सक्तीचे नियम; त्वरित इनपुट वापरकर्त्याकडे जाते. मिक्सिंगमुळे सुरक्षा भेद्यता निर्माण होते.
- साध्या स्ट्रिंगसाठी 'सामग्री' चुकीची आहे: उत्तर ब्लॉक्सची सूची आहे; पहिल्या मजकूर ब्लॉकचे मजकूर फील्ड वाचा, ब्लाइंड इंडेक्ससह सामग्री [0] मिळवण्यापूर्वी त्याचा प्रकार सत्यापित करा.
- कोडमध्ये की एम्बेड करणे: पर्यावरण व्हेरिएबल (युनिट 9) वापरा.
सखोल: सामग्री अवरोध आणि बहु-भाग उत्तरे
प्रतिसादातील सामग्री फील्ड ही सूची का आहे हे समजून घेणे हे तुम्हाला नंतर भेटणाऱ्या प्रगत वैशिष्ट्यांसाठी मूलभूत आहे. कधीकधी मॉडेल मजकूराचा एक ब्लॉक नाही, परंतु अनेक ब्लॉक्स परत करते: विचारांचा एक ब्लॉक, त्यानंतर मजकूराचा ब्लॉक; किंवा मजकूराचा ब्लॉक त्यानंतर टूल वापर ब्लॉक. म्हणूनच "उत्तर" म्हणून सामग्री[0] आंधळेपणाने मोजणे नाजूक आहे. सूचीमधून जाणे आणि प्रकारानुसार क्रमवारी लावणे हा योग्य दृष्टीकोन आहे: तुम्ही ज्या ब्लॉक्सचे प्रकार फील्ड मजकूर आहे अशा मजकूर सामग्री संकलित करा आणि इतर प्रकार (विचार, साधन) स्वतंत्रपणे हाताळा.
हा फरक सरावात काय करतो ते म्हणजे तुम्ही मॉडेलचे तर्क (असल्यास) वापरकर्त्याला न सांगता लॉग करू शकता, टूल कॉलला विभक्त लॉजिकवर पुनर्निर्देशित करू शकता आणि फक्त वास्तविक उत्तर स्क्रीनवर मुद्रित करू शकता. मॉड्यूल जसजसे पुढे जाईल (विशेषत: युनिट 4 आणि 11 मध्ये) तसतसे तुम्हाला दिसेल की ही ब्लॉक रचना प्रमाणीकरण आणि आउटपुट निर्देशित करण्यासाठी किती उपयुक्त आहे.
आणखी एक व्यावहारिक मुद्दा: तुम्ही वेगवेगळ्या प्रदाता प्लॅटफॉर्मवरून समान मॉडेलमध्ये प्रवेश करू शकता (डायरेक्ट API, क्लाउड प्रदात्याद्वारे). एंडपॉईंट ॲड्रेस आणि ऑथेंटिकेशन फॉरमॅट बदलू शकतो, तरीही मेसेज रोल्स, स्टेटलेस आणि रिस्पॉन्स स्ट्रक्चर यासारख्या मूलभूत संकल्पना समान राहतील. त्यामुळे तुम्ही कोणतेही प्लॅटफॉर्म वापरता तरीही या युनिटमधील मूलभूत गोष्टी लागू होतात.
सारांशात
LLM API विनंतीमध्ये मॉडेल, आउटपुट मर्यादा आणि संदेश सूची असते; भूमिका (सिस्टम, वापरकर्ता, सहाय्यक) मॉडेलचे वर्तन निर्धारित करतात. कॉल स्टेटलेस आहेत: तुम्ही प्रत्येक विनंतीसोबत संदर्भ ठेवता. प्रतिसाद एक संरचित वस्तू आहे; सामग्री, stop_reason आणि वापर फील्ड वाचणे आणि त्याचा अर्थ लावणे हा उत्पादनातील टिकाऊपणाचा आधार आहे.
अर्ज कार्य
तुमच्या स्वतःच्या व्यवसायातून एखादे कार्य निवडा (उदा. येणारे ई-मेल क्रमवारी लावणे, संक्षिप्त सारांश तयार करणे). कागदाच्या तुकड्यावर: (1) 4-5 नियमांसह सिस्टम प्रॉम्प्ट लिहा, (2) एक नमुना वापरकर्ता संदेश आणि 2-राउंड इतिहास असल्यास सेट करा, (3) max_tokens साठी वाजवी मूल्य निर्धारित करा आणि औचित्य लिहा, (4) दिलेल्या प्रतिसादात तुम्ही कोणती stop_reason मूल्ये हाताळाल आणि कसे.
चेकलिस्ट
- [ ] मी विनंतीचे तीन अनिवार्य भाग मोजू शकतो (मॉडेल, कमाल_टोकन्स, संदेश).
- [] मी प्रणाली, वापरकर्ता आणि सहाय्यक भूमिकांमधील फरक स्पष्ट करू शकतो.
- [ ] मला माहित आहे की कॉल स्टेटलेस आहेत आणि मला भूतकाळ वाहून नेणे आवश्यक आहे.
- मी [ ] सामग्री, stop_reason आणि वापर फील्ड वाचू शकतो आणि त्यावर टिप्पणी करू शकतो.
- [ ] max_tokens सह मी कापलेला प्रतिसाद लक्षात घेऊ शकतो आणि हाताळू शकतो.