जेव्हा तुम्ही एखाद्या वर्कफ्लोमध्ये (workflow) लार्ज लँग्वेज मॉडेलला (LLM) अशा प्रकारे जोडता की ज्यामध्ये मानवी संमतीसाठी ईमेलची गरज असते, तेव्हा मॉडेलमुळे सहसा बिघाड होत नाही. बिघाड तिथे होतो जिथे कोड संपतो आणि इनबॉक्स सुरू होतो. एक स्वायत्त रन (autonomous run) विनंती पाठवते. मग पहिली विनंती पूर्ण होण्यापूर्वीच दुसरी रन सुरू होते. एक सामायिक इनबॉक्स (shared inbox) वेगवेगळ्या प्रक्रियांमधून येणारे थ्रेड्स गोळा करतो. कोणीतरी १२ तास उशिरा आलेल्या मेसेजवर 'approve' क्लिक करते. आता तुमच्याकडे आउटपुट आहे. तुमच्याकडे निर्णय आहे. पण कोणत्या रनने काय तयार केले, किंवा ती मंजुरी खरोखर याच जनरेशनसाठी होती का, हे तुम्ही सिद्ध करू शकत नाही. मी इतके अंतर्गत ऑटोमेशन पाइपलाइन्स (automation pipelines) दुरुस्त केले आहेत की मला ही पद्धत माहित आहे. गोंधळातून ही परिस्थिती अपघातामध्ये (incident) इतक्या वेगाने बदलते की बहुतेक टीम्सना त्याची कल्पनाही नसते.

द ऑपरेशनल बाउंड्री (The Operational Boundary)

तुमच्या ऑर्केस्ट्रेटर (orchestrator) आणि ईमेल प्रोव्हायडरमधील सीमा केवळ नेटवर्कमधील अंतर नाही. ती एक 'स्टेट बाउंड्री' (state boundary) आहे. जेव्हा LLM ड्राफ्ट तयार करण्याचे काम पूर्ण करते, तेव्हा ती रन अजूनही जिवंत असते. ती प्रतीक्षा करत असते. जर तुमची सिस्टम 'सेंड' (send) या क्रियेला 'फायर-अँड-फॉरगेट' (fire-and-forget) इव्हेंट मानत असेल, तर तुम्ही आधीच तुमचा ताळमेळ गमावला आहे.

मी अशी पाइपलाइन्स पाहिली आहेत जिथे 'रिट्राय पॉलिसी' (retry policy) खूप आक्रमक असल्यामुळे एकाच रनने दोन वेगळ्या मंजुरी विनंत्या पाठवल्या. मी असेही पाहिले आहे की दुसरी रन अशा मेलबॉक्सचा वापर करते ज्यामध्ये गेल्या आठवड्याचे मेसेज अजूनही होते. मानवी मंजुरी देणाऱ्याला 'run IDs' दिसत नाहीत. त्यांना फक्त एक सब्जेक्ट लाईन आणि एक बटण दिसते. योग्य रचनेशिवाय, ते त्याच इनबॉक्समध्ये अंदाज लावतात जिथे मार्केटिंग न्यूजलेटर्स आणि मॉनिटरिंग अलर्ट्स असतात.

द नेग्लेक्टेड स्टेप (The Neglected Step)

टीम्स प्रॉम्प्ट्स ट्यून करण्यासाठी, गार्डरेल्स (guardrails) जोडण्यासाठी आणि आउटपुट बेंचमार्किंगसाठी आठवडे घालवतात. त्यानंतर ते मंजुरीची पायरी स्लॅक (Slack) चॅनेल किंवा सामायिक सपोर्ट इनबॉक्सला जोडतात आणि काम पूर्ण झाले असे समजतात. यामुळे तीन अपेक्षित समस्या निर्माण होतात:

  • सामायिक इनबॉक्स अनेक रन्सच्या इव्हेंटसाठी 'डम्पिंग ग्राउंड' बनतो. संदर्भाचा अभाव निर्माण होतो. थ्रेड्स उघडून आणि टाइमस्टॅम्प्स मॅन्युअली तपासल्याशिवाय कोणता मेसेज कोणत्या बिझनेस ट्रान्झॅक्शनचा होता, हे तुम्ही पुन्हा तयार करू शकत नाही.
  • रिट्राइमुळे पुरावे पुसले जातात. जर एखाद्या रनने त्याची मंजुरी विनंती पुन्हा पाठवली, तर मूळ मेसेज गाडला जाऊ शकतो, डिलीट होऊ शकतो किंवा ईमेल क्लायंटद्वारे 'ड्युप्लिकेट' म्हणून मार्क केला जाऊ शकतो. यामुळे ऑडिट ट्रेल (audit trail) विस्कळीत होते.
  • मानवी निर्णय सिस्टमच्या बाहेर राहतात. कोणीतरी तिकीट किंवा थेट मेसेजमध्ये "looks good" असे उत्तर देते. तो प्रतिसाद वर्कफ्लोमध्ये कधीही स्ट्रक्चर्ड डेटा (structured data) बनत नाही. कोणी काय आणि कधी म्हटले, हे पडताळण्याचा एजंटकडे कोणताही मार्ग नसतो.

जेव्हा काही चुकते आणि तुम्हाला तपासणी करायची असते, तेव्हा तुम्हाला केवळ ऐकीव माहिती मिळते. "मला वाटते की तो योग्य ईमेल होता." स्मृती म्हणजे ट्रॅसेबिलिटी (traceability) नाही. ऑडिट लॉग केवळ अंदाजांवर आधारित काम करू शकत नाही.

फ्रॉम डिलिव्हरी डिटेल टू चेकपॉइंट (From Delivery Detail to Checkpoint)

हे सुधारण्यासाठी डिझाइनमध्ये बदल आवश्यक आहे. ईमेलला केवळ एक 'डिलिव्हरी डिटेल' म्हणून पाहणे थांबवा. त्याला 'सिस्टम चेकपॉइंट' (system checkpoint) म्हणून मानण्यास सुरुवात करा. याचा अर्थ असा की प्रत्येक मेसेज हा एक 'स्टेट ट्रान्झिशन' (state transition) आहे आणि प्रत्येक स्टेट ट्रान्झिशनसाठी ओळख (identity), अधिकृतता (authorization) आणि पुरावा (evidence) आवश्यक आहे.

जेव्हा तुम्ही ही मानसिकता स्वीकारता, तेव्हा प्रश्न बदलतात. ईमेल यशस्वीरित्या पाठवला गेला की नाही, हे विचारण्याऐवजी तुम्ही विचारू लागता की कोणता रन तो पाठवतो, त्याने मागे कोणता पुरावा सोडला आणि कोणत्या नियमाने वर्कफ्लो सुरू ठेवण्यास अधिकृत केले. एजंट ईमेलचा मजकूर नक्कीच लिहू शकतो. परंतु तुमच्या प्लॅटफॉर्मने ओळख आणि पडताळणीचे मार्ग (identity and verification paths) लागू केले पाहिजेत. LLM हा लेखक आहे, तर इन्फ्रास्ट्रक्चर (infrastructure) हा नोटरी आहे.

अ मिनिमम डिझाइन (A Minimum Design)

हे तयार करण्यासाठी तुम्हाला खूप मोठ्या गुंतवणुकीची गरज नाही. माझे 'मिनिमम व्हायबल व्हर्जन' (minimum viable version) पाच हेतुपुरस्सर घटकांचा वापर करते.

  • वर्कफ्लो सुरू होताच ऑर्केस्ट्रेटर एक run_id तयार करतो. हा आयडेंटिफायर (identifier) प्रत्येक पुढील क्रियेचा कणा असतो. तो कधीही बदलत नाही आणि त्याचा पुन्हा वापर केला जात नाही.
  • प्रत्येक ईमेल कृतीमध्ये तीन फील्ड्स असतात: run_id, "approval_request" किंवा "evidence_notification" सारखे message_type लेबल, आणि policy_version स्ट्रिंग जी कोणते गव्हर्नन्स नियम सक्रिय आहेत हे ओळखते. यामुळे एक साधा मेसेज एका 'टायप्ड इव्हेंट' (typed event) मध्ये रूपांतरित होतो.
  • पुरावा (Evidence) एका अशा इनबॉक्समध्ये राहतो जो त्या रनद्वारे वेगळा (isolated) केला जातो. याचा अर्थ प्रत्येक रनसाठी वेगळा ईमेल अकाउंट असा नेहमीच होत नाही. याचा अर्थ एक समर्पित लेबल, सबफोल्डर किंवा राउटिंग नियम असू शकतो जो थ्रेड्सचे विभाजन करतो जेणेकरून एका रनचे पत्रव्यवहार दुसऱ्याशी मिसळू नये.
  • मंजुरीचा प्रतिसाद हा एक स्ट्रक्चर्ड इव्हेंट (structured event) असावा, केवळ "ok" असा मोकळा मजकूर नको. माणूस अजूनही क्लिक करतो किंवा उत्तर देतो, परंतु सिस्टम त्या कृतीचे मशीन-रीडेबल पेलोडमध्ये (machine-readable payload) रूपांतर करते, ज्यामध्ये run_id, निर्णय आणि टाइमस्टॅम्पचा उल्लेख असतो.
  • पुरावा आणि निर्णय जुळल्यासच प्रवाह पुढे सुरू राहतो. वर्कफ्लो केवळ मंजुरीवर विश्वास ठेवत नाही. LLM आउटपुट प्रोडक्शनमध्ये पोहोचण्यापूर्वी तो मूळ विनंतीच्या आधारे मंजुरी पेलोडची पडताळणी करतो.

एक उपयुक्त चेकपॉइंट काय पडताळते (What a Useful Checkpoint Validates)

एक उपयुक्त चेकपॉइंट मानवी निर्णय स्वीकारण्यापूर्वी चार अटी लागू करते.

  • प्राप्तकर्ता हा रन कॉन्टेक्स्टचा (run context) भाग असणे आवश्यक आहे. जर मंजूर करणारा (approver) या विशिष्ट वर्कफ्लो इन्स्टन्ससाठी (workflow instance) नियुक्त केलेला रिव्ह्यूअर नसेल, तर सिस्टम सिग्नल नाकारते.
  • विषय किंवा राउटिंग मेटाडेटा (routing metadata) सध्याच्या फ्लो स्टेटशी (flow state) जुळला पाहिजे. तिसऱ्या स्टेपसाठी मिळालेली मंजुरी दुसऱ्या स्टेपला बायपास करू शकत नाही.
  • टाइमस्टॅम्प (timestamp) अपेक्षित वेळेच्या मर्यादेत असणे आवश्यक आहे. टाइमआउटनंतर येणारा निर्णय नवीन रिव्ह्यू ट्रिगर केला पाहिजे, तो आपोआप मंजूर (automatic pass) होऊ नये.
  • पुरावा (evidence) दुसऱ्या कोणत्याही रनद्वारे पुन्हा वापरलेला नसावा. जर तोच मेसेज आयडी (message ID) किंवा टोकन (token) दोन वेगवेगळ्या मंजुरी विनंत्यांमध्ये दिसून आला, तर तो कोलिजन (collision) आहे आणि सिस्टमने थांबले पाहिजे.

खरी किंमत

ही पद्धत मोफत नाही. तुम्हाला अधिक मेटाडेटा साठवावा लागतो. तुम्ही एक पॉलिसी लेअर (policy layer) जोडता ज्याची देखभाल कोणालातरी करावी लागते. तुम्हाला तुमच्या टीमला मानवी निर्णय साध्या टिप्पण्यांऐवजी स्ट्रक्चर्ड डेटा (structured data) म्हणून नोंदवण्यास भाग पाडावे लागते. हे नोकरशाहीसारखे वाटू शकते. पण प्रत्यक्षात, हा एक उत्कृष्ट व्यवहार आहे.

तुम्ही स्पष्टतेसाठी वेगाचा त्याग करत आहात.