प्रत्येकजण प्रॉम्प्टवरच (prompt) वेड्यासारखा लक्ष केंद्रित करतो. ते अभिवादन (greeting) सुधारतात, टोन (tone) बदलतात आणि मॉडेल पुरेसे आपुलकीचे वाटते का याबद्दल काळजी करतात. हे केवळ लक्ष विचलित करणारे आहे. जेव्हा एखादा AI एजंट खऱ्या वापरकर्त्यांना खरोखरचे ईमेल पाठवायला सुरुवात करतो, तेव्हा धोका असा नाही की तो "Best regards" ऐवजी "Cheers" लिहितो. धोका असा आहे की, एजंटचा निर्णय आणि इनबॉक्समध्ये संदेश पोहोचणे या दरम्यान नक्की काय घडले, हे तुम्ही खात्रीने सांगू शकत नाही. मी प्रथम सीमेकडे (boundary) पाहतो. तिथेच प्रोडक्शन सिस्टिम्स (production systems) शांतपणे कोलमडतात.
करार हा कमकुवत दुवा आहे
AI डेमोमध्ये चुका माफ केल्या जातात. ब्राउझर विंडोमधील एक सुरळीत संभाषण गृहितकांच्या (assumptions) गोंधळाला लपवून ठेवते. प्रोडक्शनमध्ये, खरी असुरक्षितता तीन गोष्टींमधील करारावर (contract) अवलंबून असते: एजंटचा निर्णय, कृती कार्यान्वित करणारे टूल आणि निकालाची पडताळणी करणारी पायरी. जर ही सीमा अस्पष्ट असेल, तर सिस्टिम जोपर्यंत व्यवस्थित चालते तोपर्यंत सुंदर दिसते, पण त्यानंतर ती अचानक बिघडते. मग ती शांतपणे फेल होते, संपूर्ण ग्राहक विभागाला डुप्लिकेट संदेश पाठवते किंवा का घडले याचा कोणताही स्पष्ट रेकॉर्ड न ठेवता चुकीच्या वेळी संदेश पाठवते. प्रॉम्प्ट एखाद्या कवितेसारखा वाटू शकतो, पण त्याखालील आर्किटेक्चर (architecture) अजूनही धाग्यांनी बांधलेले असू शकते.
एजंटला मुक्तपणे लिहू देणे थांबवा
सर्वात सामान्य चूक म्हणजे एजंटला एक कोरा कागद देणे. टीम्स त्याला कच्च्या मजकुरात (raw text) ईमेलचे वर्णन करू देतात आणि नंतर त्या मजकुरातून हेतू (intent) ओळखण्यासाठी डाउनस्ट्रीम टूलवर विश्वास ठेवतात. हे अत्यंत नाजूक आहे. एक LLM योग्य हेतू सुचवू शकते, परंतु तुमच्या इन्फ्रास्ट्रक्चरला (infrastructure) कल्पकता नको आहे. त्याला एका कराराची (contract) गरज आहे. त्याला विशिष्ट फील्ड्सची गरज आहे ज्याची मशीन कोणत्याही संदिग्धतेशिवाय पडताळणी करू शकेल.
जेव्हा एखादा एजंट ईमेल विनंती (email request) पाठवतो, तेव्हा आउटपुटमध्ये नेमके तेच असावे जे प्लंबिंगला (plumbing) आवश्यक आहे:
- Template version: ईमेल बॉडीची कोणती आवृत्ती वापरली जात आहे, जेणेकरून वापरकर्त्याला काय दिसले हे तुम्हाला समजेल.
- Recipient scope: हे कोणाला मिळेल, हे युजर आयडी (user IDs) किंवा सेगमेंट नियमांद्वारे परिभाषित केलेले असावे, "ज्याने नुकतेच साइन अप केले आहे असा वापरकर्ता" यांसारख्या नैसर्गिक भाषेने नाही.
- Trace ID: एक युनिक आयडेंटिफायर जो या विनंतीचा पाठपुरावा एजंटपासून तुमच्या एक्झिक्युटरपर्यंत, ईमेल प्रोव्हायडरपर्यंत आणि तुमच्या लॉग्सपर्यंत करतो.
- Time window: हे पाठवणे कधी वैध आहे, जेणेकरून एजंटचे जुने निर्णय तासनतास नंतर मध्यरात्री ईमेल पाठवणार नाहीत.
- Idempotency: एक अशी की (key) जी एजंटने पुन्हा प्रयत्न केल्यास किंवा नेटवर्कमध्ये अडथळा आल्यास एकाच प्रकारचा संदेश दोनदा जाण्यापासून रोखते.
कच्चा मजकूर (Raw text) हे एक अत्यंत खराब API आहे. ते तातडी, प्रेक्षक आणि कृतीबद्दल संदिग्धता निर्माण करते. विशिष्ट फील्ड्स मशीन-रीडेबल (machine-readable), ऑडिट करण्यायोग्य आणि टेस्ट करण्यायोग्य असतात. ते एका अस्पष्ट सूचनेचे रूपांतर पडताळण्यायोग्य कमांडमध्ये करतात.
गद्य नाही, तर कृती
एजंटला मोकळी लेखनाची कामे देण्याऐवजी, त्याला परवानगी दिलेल्या कृतींच्या मेनूपुरते मर्यादित ठेवा. याला एका फिक्स्ड enum असलेल्या अंतर्गत API सारखे समजा. एजंट विषय ओळ (subject line) मसुदा करत नाही किंवा अभिवादानाचा विचार करत नाही. तो send_review_request किंवा send_retry_notice सारखी कृती निवडतो. त्याची सर्जनशील स्वातंत्र्य इतकीच मर्यादित असावी.
त्यानंतर एक डिटरमिनिस्टिक एक्झिक्युटर (deterministic executor) ती ॲक्शन की घेतो, व्हर्जन कंट्रोलमधून योग्य टेम्पलेट काढतो, त्यात शुद्ध (sanitized) डेटा भरतो, पडताळणी केलेल्या स्त्रोताकडून प्राप्त झालेली प्राप्तकर्त्यांची यादी भरतो आणि अंतिम कमांड तयार करतो. काय घडले पाहिजे हे एजंट ठरवतो. ते कसे घडले पाहिजे हे कंटाळवाणे, अंदाजे (predictable) कोड ठरवतो.
या विभाजनामुळे सिस्टिम टेस्ट करणे सोपे होते. तुम्ही LLM इन्फरन्स (inference) न चालवता देखील एखादी इनपुट स्थिती send_retry_notice कार्यान्वित करते की नाही याची पडताळणी करू शकता. तुमचे युनिट टेस्ट्स (unit tests) जलद आणि डिटरमिनिस्टिक होतात कारण ते मॉडेलच्या तापमानाची (temperature) नाही, तर मॅपिंग लॉजिकची तपासणी करतात. तुमचे इंटिग्रेशन टेस्ट्स (integration tests) मॉडेलचा दिवस चांगला होता की नाही यावर नाही, तर एक्झिक्युटर ॲक्शनला ईमेल सर्व्हिसशी योग्यरित्या मॅप करतो की नाही यावर लक्ष केंद्रित करतात.
पाच स्तरांमध्ये बांधणी करा
एक मजबूत सिस्टिम केवळ एका प्रॉम्प्टमधून तयार होत नाही. ती स्तरांमध्ये बांधलेली असते आणि प्रत्येक स्तर एक विशिष्ट, स्पष्ट जबाबदारी पार पाडतो.
1. बॅकएंड इव्हेंटला सुरक्षित डेटा मध्ये रूपांतरित करते.
ट्रिगर वेबहुक (webhook), डेटाबेस बदल किंवा शेड्युल केलेले जॉब असो, हा स्तर इनपुट्स शुद्ध करतो, अनपेक्षित फील्ड्स काढून टाकतो आणि एजंटला फक्त आवश्यक तेवढाच डेटा देतो. जर वेबहुक पेलोडमध्ये वीस फील्ड्स असतील पण एजंटला फक्त दोनच हवे असतील, तर फक्त ते दोनच द्या. वापरकर्त्याचा कोणताही कच्चा मजकूर तपासणीशिवाय निर्णय स्तरापर्यंत (decision layer) पोहोचू नये.
2. एजंट फिक्स्ड स्कीमामधून (fixed schema) एक कृती निवडतो.
तो संदर्भ पाहतो, निर्णय घेतो आणि आवश्यक मेटाडेटासह (metadata) पूर्व-निर्धारित ॲक्शन कीजपैकी एक आउटपुट म्हणून देतो. तो गद्य (prose) मसुदा करत नाही. तो प्राप्तकर्त्यांचा अंदाज घेत नाही. तो एक स्ट्रक्चर्ड पेलोड (structured payload) परत करतो ज्याची पडताळणी पुढचा स्तर JSON स्कीमाच्या आधारे करू शकतो.
३. टूल परवानग्या आणि आवश्यक फील्ड्सची पडताळणी करते.
या एजंट कॉन्टेक्स्टला या युजरसाठी send_review_request ट्रिगर करण्याचा अधिकार आहे का? प्राप्तकर्त्याची व्याप्ती (recipient scope) रिकामी नाही ना आणि ती परवानगी दिलेल्या मर्यादेत आहे का? तुमच्या लॉगमध्ये आयडेम्पोटन्सी की (idempotency key) उपलब्ध आणि युनिक आहे का? ट्रेस आयडी (trace ID) योग्य स्वरूपात आहे का? कोणत्याही ईमेल सर्व्हिसला स्पर्श करण्यापूर्वीच, येथे स्पष्टपणे त्रुटी दाखवा.
४. ईमेल सर्व्हिस ट्रेस आयडीसह (trace ID) पाठवल्याची नोंद करते.
तुमच्या सिस्टममधून बाहेर पडणारा प्रत्येक संदेश प्रोव्हायडरच्या API द्वारे आणि तुमच्या ऑब्झर्व्हेबिलिटी स्टॅक (observability stack) मध्ये तो ट्रेस आयडेंटिफायर सोबत नेणे आवश्यक आहे. जर एखाद्या युजरने दोन प्रती मिळाल्याची तक्रार केली, तर तुम्ही एका आयडीद्वारे क्वेरी करून नेमकी डुप्लिकेशनची सुरुवात कोठून झाली हे पाहू शकले पाहिजे: एखादे रिट्राय केलेले एजंट कॉल, एखादा अस्थिर (flaky) एक्झिक्युटर किंवा चुकीचे काम करणारे कॉलबॅक.
५. एंड-टू-एंड टेस्ट प्रत्यक्ष इनबॉक्समधील मजकूर आणि परिणामांची तपासणी करते.
प्रत्यक्ष मेलबॉक्समध्ये रेंडर केलेला संदेश उघडा. विषय ओळ (subject line) योग्यरित्या भरली आहे का? अनसबस्क्राइब लिंक काम करते का? प्रायमरी कॉल-टू-ॲक्शन (call-to-action) बटणावर क्लिक केल्यावर योग्य युजर स्टेटसह योग्य पेज उघडते का? युनिट टेस्ट पास होणे म्हणजे कोड रन झाला असा त्याचा अर्थ होतो. केवळ इनबॉक्स टेस्ट तुम्हाला सांगू शकते की ईमेल खरोखर मानवासाठी काम करतोय.
अंदाजापेक्षा पुराव्यावर भर
जेव्हा या पाइपलाइनमध्ये एखादी टेस्ट फेल होते, तेव्हा तुम्हाला पुराव्याचे चार विशिष्ट भाग लागतात. त्यापेक्षा कमी काहीही स्वीकारू नका.
- एजंटचा मूळ निर्णय. त्याने कोणती कृती निवडली आणि पूर्ण इनपुट कॉन्टेक्स्ट काय होता?
- टूलकडून मिळालेली नॉर्मलाईज्ड कमांड. टेम्पलेट, हायड्रेशन लॉजिक आणि व्हॅलिडेशन रूल्स लागू केल्यानंतर डिटरमिनिस्टिक एक्झिक्युटरने काय तयार केले?
- आयसोलेटेड इनबॉक्समधील संदेश. तुम्ही काय पाठवले असे तुम्हाला वाटते याचा लॉग नाही, तर समर्पित टेस्ट मेलबॉक्समध्ये कॅप्चर केलेला खरा MIME संदेश, हेडर्स आणि सर्व काही.
- लिंकवर क्लिक केल्यानंतरचा अंतिम परिणाम. resulting पेज स्टेट, डेटाबेस बदल किंवा बाह्य इव्हेंट, जो सिद्ध करतो की ईमेलने आपला उद्देश साध्य केला आहे.
जर एक भागही गहाळ असेल, तर तुमची टीम गृहितकांद्वारे ती पोकळी भरून काढेल. ते अंदाज लावतील. ऑटोमेशनमध्ये अंदाज लावणे महाग पडते. यामुळे तासनतास वाया जातात, विश्वास कमी होतो आणि प्रत्येक घटना एका फॉरेन्सिक मिस्ट्रीमध्ये रूपांतरित होते, ऐवजी...