જ્યારે તમે કોઈ એવા વર્કફ્લોમાં લાર્જ લેંગ્વેજ મોડેલ (LLM) ને જોડો છો જેમાં ઈમેલ દ્વારા માનવીય મંજૂરીની જરૂર હોય, ત્યારે મોડેલ ભાગ્યે જ નિષ્ફળ જાય છે. ખામી ત્યાં સર્જાય છે જ્યાં કોડ પૂરો થાય છે અને ઇનબોક્સ શરૂ થાય છે. એક ઓટોનોમસ રન (autonomous run) વિનંતી મોકલે છે. પછી પહેલું રન પૂર્ણ થાય તે પહેલાં બીજું રન શરૂ થઈ જાય છે. એક શેર કરેલ ઇનબોક્સ વિવિધ પ્રક્રિયાઓમાંથી થ્રેડ્સ એકત્રિત કરે છે. કોઈ વ્યક્તિ બાર કલાક મોડા આવેલા મેસેજ પર 'approve' ક્લિક કરે છે. હવે તમારી પાસે આઉટપુટ છે. તમારી પાસે નિર્ણય છે. પરંતુ તમે સાબિત કરી શકતા નથી કે કયા રને શું બનાવ્યું હતું, અથવા તે મંજૂરી ખરેખર આ જ જનરેશન માટે હતી કે નહીં. મેં આ પ્રકારની પેટર્ન જાણવા માટે પૂરતા પ્રમાણમાં ઇન્ટરનલ ઓટોમેશન પાઇપલાઇન્સને સુધારી છે. તે મૂંઝવણમાંથી ઘટના (incident) માં એટલી ઝડપથી ફેરવાય છે જેટલી મોટાભાગની ટીમો અપેક્ષા રાખતી નથી.
ઓપરેશનલ સીમા (The Operational Boundary)
તમારા ઓર્કેસ્ટ્રેટર (orchestrator) અને તમારા ઈમેલ પ્રોવાઈડર વચ્ચેની સીમા માત્ર નેટવર્ક હોપ નથી. તે એક સ્ટેટ બાઉન્ડ્રી (state boundary) છે. જ્યારે LLM ડ્રાફ્ટ જનરેટ કરવાનું પૂરું કરે છે, ત્યારે રન હજુ પણ ચાલુ હોય છે. તે રાહ જોઈ રહ્યું હોય છે. જો તમારું સિસ્ટમ 'સેન્ડ' ને 'ફાયર-એન્ડ-ફોર્ગેટ' (fire-and-forget) ઇવેન્ટ તરીકે ગણે છે, તો તમે પહેલેથી જ કંટ્રોલ ગુમાવી દીધો છે.
મેં એવી પાઇપલાઇન્સ જોઈ છે જ્યાં રિટ્રાય પોલિસી (retry policy) ખૂબ જ આક્રમક હોવાને કારણે એક જ રન બે અલગ-અલગ મંજૂરી વિનંતીઓ મોકલે છે. મેં જોયું છે કે બીજું રન એવા મેઇલબોક્સનો ઉપયોગ કરે છે જેમાં હજુ પણ ગયા અઠવાડિયાના મેસેજ પડ્યા હોય છે. માનવીય મંજૂર કરનાર વ્યક્તિ રન આઈડી (run IDs) જોતી નથી. તેઓ માત્ર વિષય (subject line) અને એક બટન જુએ છે. માળખાગત વ્યવસ્થા વિના, તેઓ એ જ ઇનબોક્સમાં અંદાજ લગાવતા હોય છે જ્યાં માર્કેટિંગ ન્યૂઝલેટર્સ અને મોનિટરિંગ એલર્ટ્સ હોય છે.
અવગણવામાં આવેલું પગલું (The Neglected Step)
ટીમો પ્રોમ્પ્ટ્સને ટ્યુન કરવામાં, ગાર્ડરેલ્સ (guardrails) ઉમેરવામાં અને આઉટપુટના બેન્ચમાર્કિંગમાં અઠવાડિયા વિતાવે છે. પછી તેઓ મંજૂરીના સ્ટેપને Slack ચેનલ અથવા શેર કરેલા સપોર્ટ ઇનબોક્સ સાથે જોડી દે છે અને કામ પૂરું થયું એમ માની લે છે. આનાથી ત્રણ અનુમાનિત સમસ્યાઓ ઊભી થાય છે:
- શેર કરેલ ઇનબોક્સ અનેક રનમાંથી આવતી ઇવેન્ટ્સ માટે ડમ્પિંગ ગ્રાઉન્ડ બની જાય છે. સંદર્ભ (context) ખોવાઈ જાય છે. થ્રેડ્સ ખોલ્યા વગર અને ટાઈમસ્ટેમ્પ મેન્યુઅલી તપાસ્યા વગર તમે કયો મેસેજ કયા બિઝનેસ ટ્રાન્ઝેક્શનનો હતો તે ફરીથી જાણી શકતા નથી.
- રિટ્રાય્સ (Retries) પુરાવાઓને ઓવરરાઈટ કરી દે છે. જો કોઈ રન તેની મંજૂરી વિનંતી ફરીથી મોકલે છે, તો મૂળ મેસેજ દબાઈ શકે છે, ડિલીટ થઈ શકે છે અથવા કોઈ ઈમેલ ક્લાયન્ટ દ્વારા ડુપ્લીકેટ તરીકે માર્ક કરી દેવામાં આવે છે. આનાથી ઓડિટ ટ્રેલ (audit trail) નબળી પડે છે.
- માનવીય નિર્ણયો સિસ્ટમની બહાર રહી જાય છે. કોઈ વ્યક્તિ ટિકિટ અથવા ડાયરેક્ટ મેસેજમાં "looks good" જવાબ આપે છે. તે અભિપ્રાય ક્યારેય વર્કફ્લોની અંદર સ્ટ્રક્ચર્ડ ડેટા બનતો નથી. એજન્ટ પાસે કોણે શું કહ્યું અથવા ક્યારે કહ્યું તે ચકાસવાનો કોઈ રસ્તો હોતો નથી.
જ્યારે કંઈક ખોટું થાય છે અને તમારે તપાસ કરવાની જરૂર પડે છે, ત્યારે તમને માત્ર સાંભળેલી વાતો મળે છે. "મને લાગે છે કે તે સાચો ઈમેલ હતો." યાદશક્તિ એ ટ્રેસેબિલિટી (traceability) નથી. ઓડિટ લોગ માત્ર અંદાજ પર કામ કરી શકતો નથી.
ડિલિવરી ડિટેલથી ચેકપોઈન્ટ સુધી (From Delivery Detail to Checkpoint)
આને સુધારવા માટે ડિઝાઇનમાં ફેરફારની જરૂર છે. ઈમેલને માત્ર ડિલિવરીની વિગત તરીકે જોવાનું બંધ કરો. તેને સિસ્ટમ ચેકપોઈન્ટ તરીકે ગણવાનું શરૂ કરો. તેનો અર્થ એ છે કે દરેક મેસેજ એ સ્ટેટ ટ્રાન્ઝિશન (state transition) છે, અને દરેક સ્ટેટ ટ્રાન્ઝિશન માટે ઓળખ (identity), અધિકૃતતા (authorization) અને પુરાવા (evidence) ની જરૂર છે.
જ્યારે તમે આ માનસિકતા અપનાવો છો, ત્યારે પ્રશ્નો બદલાઈ જાય છે. તમે એ પૂછવાનું બંધ કરો છો કે ઈમેલ સફળતાપૂર્વક મોકલવામાં આવ્યો કે નહીં. તમે એ પૂછવાનું શરૂ કરો છો કે કયા રને તે મોકલ્યો હતો, તેણે કયા પુરાવા છોડ્યા હતા, અને કયા નિયમે વર્કફ્લોને આગળ વધવાની મંજૂરી આપી હતી. એજન્ટ ચોક્કસપણે ઈમેલ બોડી લખી શકે છે. પરંતુ તમારા પ્લેટફોર્મે ઓળખ અને વેરિફિકેશન પાથ (verification paths) લાગુ કરવા જ જોઈએ. LLM લેખક છે. ઇન્ફ્રાસ્ટ્રક્ચર નોટરી (notary) છે.
એક લઘુત્તમ ડિઝાઇન (A Minimum Design)
આ બનાવવા માટે તમારે મોટી મૂડીની જરૂર નથી. મારું મિનિમમ વાયેબલ વર્ઝન (minimum viable version) પાંચ ચોક્કસ ભાગોનો ઉપયોગ કરે છે.
- જ્યારે વર્કફ્લો શરૂ થાય છે, ત્યારે ઓર્કેસ્ટ્રેટર તરત જ એક
run_idબનાવે છે. આ આઈડેન્ટિફાયર દરેક પછીના પગલાનો મુખ્ય આધાર છે. તે ક્યારેય બદલાતું નથી અને તેનો ફરીથી ઉપયોગ કરવામાં આવતો નથી. - દરેક ઈમેલ એક્શનમાં ત્રણ ફિલ્ડ્સ હોય છે:
run_id, "approval_request" અથવા "evidence_notification" જેવુંmessage_typeલેબલ, અનેpolicy_versionસ્ટ્રિંગ જે ઓળખાવે છે કે કયા ગવર્નન્સ નિયમો સક્રિય છે. આ એક સાદા મેસેજને ટાઈપ્ડ ઇવેન્ટમાં ફેરવે છે. - પુરાવા (Evidence) રન દ્વારા અલગ કરેલા ઇનબોક્સમાં રહે છે. તેનો અર્થ એ નથી કે દરેક રન માટે અલગ ઈમેલ એકાઉન્ટ હોવું જોઈએ. તેનો અર્થ સમર્પિત લેબલ, સબફોલ્ડર અથવા રાઉટિંગ નિયમ હોઈ શકે છે જે થ્રેડ્સને અલગ કરે છે જેથી એક રનનો પત્રવ્યવહાર બીજા સાથે ભળતો નથી.
- મંજૂરીનો પ્રતિસાદ એક સ્ટ્રક્ચર્ડ ઇવેન્ટ હોવો જોઈએ, માત્ર ફ્રી-ટેક્સ્ટ "ok" નહીં. માનવી હજુ પણ ક્લિક કરે છે અથવા જવાબ આપે છે, પરંતુ સિસ્ટમ તે ક્રિયાને મશીન-રીડેબલ પેલોડ (machine-readable payload) માં રૂપાંતરિત કરે છે જે
run_id, નિર્ણય અને ટાઈમસ્ટેમ્પ દર્શાવે છે. - પ્રવાહ ત્યારે જ આગળ વધે છે જો પુરાવા અને નિર્ણય મેળ ખાતા હોય. વર્કફ્લો મંજૂરી પર અલગથી વિશ્વાસ કરતો નથી. તે LLM આઉટપુટને પ્રોડક્શનમાં પહોંચવા દેતા પહેલા મૂળ વિનંતી સામે મંજૂરી પેલોડને વેરિફાય કરે છે.
એક ઉપયોગી ચેકપોઈન્ટ શું વેરિફાય કરે છે (What a Useful Checkpoint Validates)
એક ઉપયોગી ચેકપોઈન્ટ માનવ નિર્ણય સ્વીકારતા પહેલા ચાર શરતો લાગુ કરે છે.
- પ્રાપ્તકર્તા run context નો હોવો જોઈએ. જો મંજૂર કરનાર (approver) આ ચોક્કસ વર્કફ્લો ઇન્સ્ટન્સ (workflow instance) માટે નિયુક્ત સમીક્ષક ન હોય, તો સિસ્ટમ સિગ્નલને નકારી દે છે.
- વિષય અથવા રૂટિંગ મેટાડેટા (routing metadata) વર્તમાન ફ્લો સ્ટેટ (flow state) સાથે મેળ ખાવો જોઈએ. સ્ટેપ ત્રણ માટેની મંજૂરી સ્ટેપ બે ને બાયપાસ કરી શકતી નથી.
- ટાઈમસ્ટેમ્પ (timestamp) અપેક્ષિત સમયગાળાની અંદર હોવો જોઈએ. ટાઈમઆઉટ પછી આવેલ નિર્ણય નવી સમીક્ષા (fresh review) માટે ટ્રિગર થવો જોઈએ, આપમેળે પાસ (automatic pass) થવો જોઈએ નહીં.
- પુરાવા (evidence) અન્ય કોઈ run દ્વારા ફરીથી ઉપયોગમાં લેવામાં આવ્યા ન હોવા જોઈએ. જો સમાન મેસેજ ID અથવા ટોકન બે અલગ-અલગ મંજૂરી વિનંતીઓમાં દેખાય, તો તે કોલિઝન (collision) છે, અને સિસ્ટમે અટકવું જોઈએ.
વાસ્તવિક ખર્ચ
આ પેટર્ન મફત નથી. તમે વધુ મેટાડેટા સંગ્રહિત કરો છો. તમે એક પોલિસી લેયર (policy layer) ઉમેરો છો જેને કોઈએ જાળવવું પડે છે. તમે તમારી ટીમને સામાન્ય ટિપ્પણીઓને બદલે માનવ નિર્ણયોને સ્ટ્રક્ચર્ડ ડેટા (structured data) તરીકે લોગ કરવા માટે મજબૂર કરો છો. તે અમલદારશાહી (bureaucracy) જેવું લાગે છે. વ્યવહારમાં, તે એક ઉત્તમ સોદો છે.
તમે સ્પષ્ટતા માટે ઝડપ સાથે સમજૂતી કરી રહ્યા છો.