మీరు ఒక లార్జ్ లాంగ్వేజ్ మోడల్‌ను (LLM), ఇమెయిల్ ద్వారా మనిషి ఆమోదం (yes) తెలపాల్సిన వర్క్‌ఫ్లోలోకి అనుసంధానించినప్పుడు, మోడల్ వల్ల సమస్యలు రావడం చాలా అరుదు. కోడ్ ముగిసి, ఇన్‌బాక్స్ మొదలయ్యే చోట సమస్యలు తలెత్తుతాయి. ఒక స్వయంప్రతిపత్తి కలిగిన రన్ (autonomous run) ఒక రిక్వెస్ట్‌ను పంపిస్తుంది. మొదటిది పూర్తయ్యేలోపే మరొక రన్ ప్రారంభమవుతుంది. ఒకే షేర్డ్ ఇన్‌బాక్స్ వివిధ ప్రాసెస్ల నుండి వచ్చే త్రెడ్స్‌ను సేకరిస్తుంది. పన్నెండు గంటల ఆలస్యంగా వచ్చిన మెసేజ్‌పై ఎవరో 'approve' క్లిక్ చేస్తారు. ఇప్పుడు మీ దగ్గర అవుట్‌పుట్ ఉంది, ఒక నిర్ణయం కూడా ఉంది. కానీ ఏ రన్ వల్ల ఏది వచ్చిందో, లేదా ఆ ఆమోదం ఈ జనరేషన్ కోసమేనా అనేది మీరు నిరూపించలేరు. ఇలాంటి ప్యాటర్న్‌లను గుర్తించేంత వరకు నేను చాలా ఇంటర్నల్ ఆటోమేషన్ పైప్‌లైన్‌లను సరిచేసి ఉన్నాను. ఇది గందరగోళం నుండి ఒక పెద్ద సమస్యగా (incident) చాలా వేగంగా మారుతుంది.

ఆపరేషనల్ బౌండరీ (The Operational Boundary)

మీ ఆర్కెస్ట్రేటర్ (orchestrator) మరియు మీ ఇమెయిల్ ప్రొవైడర్ మధ్య ఉన్న బౌండరీ కేవలం నెట్‌వర్క్ హప్ మాత్రమే కాదు. అది ఒక స్టేట్ బౌండరీ (state boundary). LLM ఒక డ్రాఫ్ట్‌ను జనరేట్ చేసిన తర్వాత కూడా, ఆ రన్ ఇంకా కొనసాగుతూనే ఉంటుంది. అది వేచి చూస్తుంది. మీ సిస్టమ్ 'send' ప్రక్రియను 'fire-and-forget' (పంపించి వదిలేయడం) ఈవెంట్‌గా పరిగణిస్తే, మీరు ఇప్పటికే నియంత్రణను కోల్పోయినట్లే.

రిట్రై పాలసీ (retry policy) చాలా వేగంగా ఉండటం వల్ల, ఒకే రన్ రెండు వేర్వేరు అప్రూవల్ రిక్వెస్ట్‌లను పంపే పైప్‌లైన్‌లను నేను చూశాను. గత వారం మెసేజ్‌లు ఇంకా ఉన్న మెయిల్‌బాక్స్‌ను మరొక రన్ తిరిగి ఉపయోగించడం కూడా చూశాను. మనిషి (approver) రన్ ఐడిలను (run IDs) చూడరు. వారు కేవలం సబ్జెక్ట్ లైన్ మరియు ఒక బటన్‌ను మాత్రమే చూస్తారు. సరైన నిర్మాణం లేకపోతే, మార్కెటింగ్ న్యూస్‌లెటర్లు మరియు మానిటరింగ్ అలర్ట్‌లు ఉండే ఇన్‌బాక్స్‌లోనే వారు ఊహించి నిర్ణయాలు తీసుకోవాల్సి వస్తుంది.

విస్మరించబడిన దశ (The Neglected Step)

టీమ్‌లు ప్రాంప్ట్‌లను ట్యూన్ చేయడానికి, గార్డ్‌రైల్స్ (guardrails) జోడించడానికి మరియు అవుట్‌పుట్‌లను బెంచ్‌మార్క్ చేయడానికి వారాల తరబడి సమయం కేటాయిస్తారు. ఆ తర్వాత అప్రూవల్ దశను ఒక Slack ఛానెల్‌కు లేదా షేర్డ్ సపోర్ట్ ఇన్‌బాక్స్‌కు అనుసంధానించి పని పూర్తయిందని అనుకుంటారు. దీనివల్ల మూడు ఊహించదగిన సమస్యలు తలెత్తుతాయి:

  • షేర్డ్ ఇన్‌బాక్స్ అనేది అనేక రన్‌ల నుండి వచ్చే ఈవెంట్‌ల డంపింగ్ గ్రౌండ్‌గా మారుతుంది. సందర్భం (context) దెబ్బతింటుంది. త్రెడ్స్‌

ఒక ఉపయోగకరమైన చెక్‌పాయింట్, మానవ నిర్ణయాన్ని అంగీకరించే ముందు నాలుగు షరతులను అమలు చేస్తుంది.

  • స్వీకర్త రన్ కాంటెక్స్ట్‌కు చెందిన వ్యక్తి అయి ఉండాలి. ఒకవేళ ఆమోదించే వ్యక్తి ఈ నిర్దిష్ట వర్క్‌ఫ్లో ఇన్‌స్టాన్స్‌కు కేటాయించిన సమీక్షకుడు కాకపోతే, సిస్టమ్ ఆ సిగ్నల్‌ను తిరస్కరిస్తుంది.
  • సబ్జెక్ట్ లేదా రూటింగ్ మెటాడేటా ప్రస్తుత ఫ్లో స్టేట్‌తో సరిపోలాలి. మూడవ దశకు సంబంధించిన ఆమోదం, రెండవ దశను దాటవేయదు.
  • టైమ్‌స్టాంప్ ఆశించిన కాలపరిమితి (window) లోపల ఉండాలి. టైమ్ అవుట్ అయిన తర్వాత వచ్చే నిర్ణయం కొత్త సమీక్షను ప్రారంభించాలి తప్ప, ఆటోమేటిక్‌గా అనుమతించకూడదు.
  • ఆధారాలను (evidence) మరొక రన్ కోసం మళ్ళీ ఉపయోగించకూడదు. ఒకే మెసేజ్ ID లేదా టోకెన్ రెండు వేర్వేరు ఆమోద అభ్యర్థనలలో కనిపిస్తే, అది కొలిజన్ (collision) అవుతుంది మరియు సిస్టమ్ ఆగిపోవాలి.

అసలు ఖర్చు

ఈ నమూనా ఉచితం కాదు. మీరు ఎక్కువ మెటాడేటాను నిల్వ చేయాల్సి ఉంటుంది. ఎవరైనా నిర్వహించాల్సిన పాలసీ లేయర్‌ను మీరు జోడిస్తారు. మీ బృందం మానవ నిర్ణయాలను కేవలం వ్యాఖ్యలుగా కాకుండా, స్ట్రక్చర్డ్ డేటాగా నమోదు చేసేలా మీరు చేయాల్సి ఉంటుంది. ఇది బ్యూరోక్రసీలా అనిపించవచ్చు. కానీ వాస్తవానికి, ఇది ఒక అద్భుతమైన లావాదేవీ.

మీరు వేగాన్ని స్పష్టత కోసం వదులుకుంటున్నారు.