ஒரு பெரிய மொழி மாதிரியை (LLM), ஒரு மனிதன் மின்னஞ்சல் மூலம் 'ஆம்' என்று சொல்ல வேண்டிய பணிப்பாய்வோடு (workflow) இணைக்கும்போது, அந்த மாதிரி தான் பெரும்பாலும் தோல்வியடைவதில்லை. தோல்வி என்பது குறியீடு (code) முடிந்து மின்னஞ்சல் பெட்டி (inbox) தொடங்கும் இடத்தில்தான் நிகழ்கிறது. ஒரு தன்னாட்சி இயக்கம் (autonomous run) ஒரு கோரிக்கையை அனுப்புகிறது. முதல் இயக்கம் முடிவதற்கு முன்பே மற்றொரு இயக்கம் தொடங்குகிறது. ஒரு பகிரப்பட்ட மின்னஞ்சல் பெட்டி பல்வேறு செயல்முறைகளிலிருந்து வரும் விவாதத் தொடர்களைச் சேகரிக்கிறது. பன்னிரண்டு மணி நேரம் தாமதமாக வந்த ஒரு செய்திக்கு யாரோ 'அனுமதிக்கிறேன்' (approve) என்று கிளிக் செய்கிறார்கள். இப்போது உங்களிடம் வெளியீடு உள்ளது. உங்களிடம் ஒரு முடிவு உள்ளது. ஆனால் எந்த இயக்கம் எதை உருவாக்கியது அல்லது அந்த அனுமதி இந்தத் தலைமுறைக்காக (generation) ஒதுக்கப்பட்டதா இல்லையா என்பதை உங்களால் நிரூபிக்க முடியாது. இத்தகைய முறையைச் சரிசெய்யும் போது நான் பார்த்த அனுபவத்திலிருந்து இதைச் சொல்கிறேன். இது பெரும்பாலான குழுக்கள் எதிர்பார்ப்பதை விட மிக வேகமாக குழப்பத்திலிருந்து ஒரு விபத்தாக (incident) மாறுகிறது.

செயல்பாட்டு எல்லை (The Operational Boundary)

உங்கள் ஒருங்கிணைப்பாளர் (orchestrator) மற்றும் மின்னஞ்சல் வழங்குநருக்கு இடையிலான எல்லை என்பது வெறும் நெட்வொர்க் தாவல் (network hop) மட்டுமல்ல. அது ஒரு நிலை எல்லை (state boundary). LLM ஒரு வரைவை (draft) உருவாக்கி முடித்தாலும், அந்த இயக்கம் (run) இன்னும் உயிர்ப்புடன் தான் இருக்கிறது. அது காத்திருக்கிறது. உங்கள் அமைப்பு மின்னஞ்சலை அனுப்புவதை 'அனுப்பிவிட்டு மறந்துவிடுவது' (fire-and-forget) போன்ற ஒரு நிகழ்வாகக் கருதினால், நீங்கள் ஏற்கனவே தொடர்பைத் தவறவிட்டுவிட்டீர்கள் என்று அர்த்தம்.

மறுமுயற்சி கொள்கை (retry policy) மிகவும் தீவிரமாக இருந்ததால், ஒரே இயக்கம் இரண்டு தனித்தனி அனுமதி கோரிக்கைகளை உருவாக்கிய நிகழ்வுகளை நான் பார்த்திருக்கிறேன். கடந்த வாரச் செய்திகளை இன்னும் வைத்திருக்கும் ஒரு மின்னஞ்சல் பெட்டியை மற்றொரு இயக்கம் மீண்டும் பயன்படுத்தியதையும் நான் பார்த்திருக்கிறேன். மனித அங்கீகரிப்பாளர் (approver) run IDs-களைப் பார்ப்பதில்லை. அவர்கள் ஒரு தலைப்பreadline (subject line) மற்றும் ஒரு பொத்தானைப் பார்க்கிறார்கள். முறையான கட்டமைப்பு இல்லையென்றால், அவர்கள் மார்க்கெட்டிங் செய்திகள் மற்றும் கண்காணிப்பு எச்சரிக்கைகள் (monitoring alerts) இருக்கும் அதே மின்னஞ்சல் பெட்டியிலேயே யூகத்தின் அடிப்படையில் செயல்படுகிறார்கள்.

புறக்கணிக்கப்பட்ட படி (The Neglected Step)

குழுக்கள் ப்ராம்ப்ட்களை (prompts) மேம்படுத்தவும், பாதுகாப்பு வளையங்களை (guardrails) சேர்க்கவும், வெளியீடுகளைச் சரிபார்க்கவும் வாரக்கணக்கில் செலவிடுவார்கள். பின்னர் அவர்கள் அந்த அனுமதிப் படிநிலையை ஒரு Slack சேனல் அல்லது பகிரப்பட்ட ஆதரவு மின்னஞ்சல் பெட்டியுடன் இணைத்துவிட்டு, வேலை முடிந்துவிட்டது என்று கூறிவிடுவார்கள். இது மூன்று கணிக்கக்கூடிய பாதிப்புகளை உருவாக்குகிறது:

  • ஒரு பகிரப்பட்ட மின்னஞ்சல் பெட்டி பல இயக்கங்களிலிருந்து வரும் நிகழ்வுகளின் குப்பைத் தொட்டியாக மாறுகிறது. சூழல் (context) சிதைகிறது. விவாதத் தொடர்களைத் திறந்து, நேர முத்திரைகளை (timestamps) ஒவ்வொன்றாகப் பார்க்காமல், எந்தச் செய்தி எந்த வணிகப் பரிவர்த்தனைக்குச் சொந்தமானது என்பதை உங்களால் மீண்டும் கட்டமைக்க முடியாது.
  • மறுமுயற்சிகள் (Retries) ஆதாரங்களை அழித்துவிடுகின்றன. ஒரு இயக்கம் தனது அனுமதி கோரிக்கையை மீண்டும் அனுப்பினால், அசல் செய்தி மறைக்கப்படலாம், நீக்கப்படலாம் அல்லது ஒரு மின்னஞ்சல் கிளையன்ட் அதைத் திரும்ப வந்த செய்தி (duplicate) என்று குறிக்கலாம். தணிக்கைப் பாதை (audit trail) சிதைகிறது.
  • மனித முடிவுகள் அமைப்பிற்கு வெளியே மிதக்கின்றன. யாரோ ஒரு டிக்கெட் அல்லது நேரடிச் செய்தியில் "பார்க்க நன்றாக உள்ளது" (looks good) என்று பதிலளிக்கிறார்கள். அந்த உணர்வு பணிப்பாய்விற்குள் ஒரு கட்டமைக்கப்பட்ட தரவாக (structured data) மாறுவதில்லை. யார், என்ன, எப்போது சொன்னார்கள் என்பதைச் சரிபார்க்க ஏஜென்டிடம் (agent) வழியில்லை.

ஏதோ ஒன்று தவறாக நடந்து நீங்கள் விசாரிக்க வேண்டியிருக்கும் போது, உங்களுக்குக் கிடைப்பது வெறும் வாய்மொழிச் சாட்சியங்கள் மட்டுமே. "அது சரியான மின்னஞ்சல் என்று நினைக்கிறேன்." நினைவாற்றல் என்பது ஒரு தணிக்கைப் பாதை (traceability) அல்ல. ஒரு தணிக்கைப் பதிவால் (audit log) வெறும் யூகத்தை உள்வாங்க முடியாது.

விநியோகத் தகவலில் இருந்து சரிபார்ப்புப் புள்ளி வரை (From Delivery Detail to Checkpoint)

இதைச் சரிசெய்ய ஒரு வடிவமைப்பு மாற்றம் தேவை. மின்னஞ்சலை ஒரு விநியோகத் தகவல் (delivery detail) என்று நினைப்பதை நிறுத்துங்கள். அதை ஒரு கணினிச் சரிபார்ப்புப் புள்ளியாக (system checkpoint) கருதத் தொடங்குங்கள். அதாவது ஒவ்வொரு செய்தியும் ஒரு நிலை மாற்றம் (state transition), மேலும் ஒவ்வொரு நிலை மாற்றத்திற்கும் அடையாளம் (identity), அங்கீகாரம் (authorization) மற்றும் ஆதாரம் (evidence) தேவை.

நீங்கள் இந்த மனநிலையைத் தழுவும்போது, கேள்விகள் மாறுகின்றன. மின்னஞ்சல் வெற்றிகரமாக அனுப்பப்பட்டதா என்று கேட்பதை நிறுத்திவிட்டு, எந்த இயக்கம் அதை அனுப்பியது, அது என்ன ஆதாரத்தை விட்டுச் சென்றது மற்றும் எந்த விதி பணிப்பாய்வைத் தொடர அனுமதித்தது என்று கேட்கத் தொடங்குவீர்கள். ஏஜென்ட் (agent) மின்னஞ்சல் உள்ளடக்கத்தை நிச்சயமாக எழுத முடியும். ஆனால் உங்கள் தளம் அடையாளம் மற்றும் சரிபார்ப்புப் பாதைகளை (identity and verification paths) கட்டாயமாக்க வேண்டும். LLM என்பது எழுத்தாளர். உள்கட்டமைப்பு (infrastructure) என்பது சான்றளிப்பவர் (notary).

ஒரு குறைந்தபட்ச வடிவமைப்பு (A Minimum Design)

இதை உருவாக்க உங்களுக்குப் பெரும் செல்வம் தேவையில்லை. எனது குறைந்தபட்ச சாத்தியமான பதிப்பு (minimum viable version) ஐந்து திட்டமிட்ட கூறுகளைப் பயன்படுத்துகிறது.

  • பணிப்பாய்வு தொடங்கும் துல்லியமான தருணத்தில் ஒருங்கிணைப்பாளர் (orchestrator) ஒரு run_id-ஐ உருவாக்குகிறார். இந்த அடையாளங்காட்டி அடுத்தடுத்த ஒவ்வொரு செயலுக்கும் முதுகெலும்பாக அமைகிறது. இது ஒருபோதும் மாறாது, மேலும் மீண்டும் பயன்படுத்தப்படாது.
  • ஒவ்வொரு மின்னஞ்சல் செயலும் மூன்று புலங்களைக் (fields) கொண்டுள்ளது: run_id, "approval_request" அல்லது "evidence_notification" போன்ற ஒரு message_type லேபிள், மற்றும் எந்த நிர்வாக விதிகள் (governance rules) செயல்பாட்டில் உள்ளன என்பதைக் குறிக்கும் ஒரு policy_version சரம் (string). இது ஒரு சாதாரண செய்தியை ஒரு வகைப்படுத்தப்பட்ட நிகழ்வாக (typed event) மாற்றுகிறது.
  • ஆதாரம் (Evidence) அந்த இயக்கத்தால் தனிமைப்படுத்தப்பட்ட ஒரு மின்னஞ்சல் பெட்டியில் இருக்கும். இதற்கு எப்போதும் ஒவ்வொரு இயக்கத்திற்கும் ஒரு தனி மின்னஞ்சல் கணக்கு என்று அர்த்தமல்ல. இது ஒரு பிரத்யேக லேபிள் (label), ஒரு துணைத் கோப்பு (subfolder) அல்லது விவாதத் தொடர்களைப் பிரிக்கும் ஒரு வழிமுறை (routing rule) ஆகியவற்றைக் குறிக்கலாம், இதனால் ஒரு இயக்கத்தின் தொடர்பு மற்றொன்றுடன் குழப்பமடையாது.
  • அனுமதிப் பதில் (approval response) என்பது ஒரு கட்டமைக்கப்பட்ட நிகழ்வாக (structured event) இருக்க வேண்டும், வெறும் "ok" என்ற உரையாக இருக்கக்கூடாது. மனிதன் இன்னும் கிளிக் செய்யலாம் அல்லது பதிலளிக்கலாம், ஆனால் அந்தச் செயல் run_id, முடிவு மற்றும் நேர முத்திரை ஆகியவற்றைக் குறிப்பிடும் இயந்திரம் வாசிக்கக்கூடிய தரவாக (machine-readable payload) மாற்றப்பட வேண்டும்.
  • ஆதாரம் மற்றும் முடிவு ஆகியவை ஒத்துப்போகும் போது மட்டுமே செயல்முறை தொடரும். பணிப்பாய்வு அனுமதியைத் தனித்து நம்புவதில்லை. LLM வெளியீடு உற்பத்தியை (production) சென்றடைவதற்கு முன், அது அசல் கோரிக்கையுடன் அனுமதித் தரவைச் (approval payload) சரிபார்க்கிறது.

ஒரு பயனுள்ள சரிபார்ப்புப் புள்ளி எதைச் சரிபார்க்கிறது (What a Useful Checkpoint Validates)

ஒரு பயனுள்ள செக்பாயிண்ட் (checkpoint), ஒரு மனித முடிவை ஏற்றுக்கொள்வதற்கு முன் நான்கு நிபந்தனைகளை உறுதி செய்கிறது.

  • பெறுநர் 'run context'-இல் இருக்க வேண்டும். அங்கீகரிப்பவர் (approver) இந்த குறிப்பிட்ட பணிப்பாய்வு நிகழ்விற்கான (workflow instance) ஒதுக்கப்பட்ட மதிப்பாய்வாளர் இல்லை என்றால், சிஸ்டம் அந்த சிக்னலை நிராகரிக்கும்.
  • பொருள் (subject) அல்லது ரூட்டிங் மெட்டாடேட்டா தற்போதைய ஓட்ட நிலைக்கு (flow state) பொருந்த வேண்டும். படி மூன்றுக்கான அங்கீகாரம், படி இரண்டைத் தவிர்க்காது.
  • கால முத்திரை (timestamp) எதிர்பார்க்கப்படும் கால வரம்பிற்குள் இருக்க வேண்டும். காலாவதி நேரத்திற்குப் (timeout) பிறகு வரும் ஒரு முடிவு, தானியங்கி அனுமதியைக் கொடுக்காமல், ஒரு புதிய மதிப்பாய்வைத் தூண்ட வேண்டும்.
  • சான்று (evidence) வேறொரு ரன்னால் (run) மீண்டும் பயன்படுத்தப்படக்கூடாது. ஒரே மெசேஜ் ID அல்லது டோக்கன் இரண்டு தனித்தனி அங்கீகாரக் கோரிக்கைகளில் காணப்பட்டால், அது ஒரு மோதல் (collision) எனக் கருதப்பட்டு, சிஸ்டம் நிறுத்தப்பட வேண்டும்.

உண்மையான விலை

இந்த முறை இலவசமானது அல்ல. நீங்கள் அதிக மெட்டாடேட்டாவைச் சேமிக்க வேண்டியிருக்கும். யாராவது பராமரிக்க வேண்டிய ஒரு கொள்கை அடுக்கை (policy layer) நீங்கள் சேர்க்கிறீர்கள். உங்கள் குழுவினர் மனித முடிவுகளை சாதாரணக் கருத்துகளாகப் பதிவு செய்வதற்குப் பதிலாக, அவற்றை கட்டமைக்கப்பட்ட தரவாகப் (structured data) பதிவு செய்ய நீங்கள் கட்டாயப்படுத்துகிறீர்கள். இது அதிகாரத்துவமாகத் (bureaucracy) தோன்றலாம். ஆனால் நடைமுறையில், இது ஒரு சிறந்த வர்த்தகம்.

நீங்கள் வேகத்திற்குப் பதிலாகத் தெளிவைப் பெறுகிறீர்கள்.