લૂપ એન્જિનિયરિંગ (Loop engineering) અત્યારે ચર્ચામાં છે. કોઈપણ ટેકનિકલ ફોરમ સ્ક્રોલ કરો અને તમને એવા અવાજો મળશે જે દલીલ કરી રહ્યા છે કે આપણે AI એજન્ટ્સને માત્ર સ્માર્ટ પ્રોમ્પ્ટ્સ દ્વારા તાલીમ આપવા માટેના ચેટબોટ્સ તરીકે જોવાનું બંધ કરવું જોઈએ. તેના બદલે, તેઓ કહે છે કે આપણે લૂપ્સ ડિઝાઇન કરવા જોઈએ: સ્વાયત્ત ચક્રો (autonomous cycles) જે એજન્ટને આયોજન કરવા, અમલ કરવા, પોતાના કામની તપાસ કરવા અને આપણે સૂતા હોઈએ ત્યારે પણ પુનરાવર્તન (iterate) કરવા દે છે. આ પ્રસ્તાવ આકર્ષક છે. જો લૂપ સારી રીતે બનાવવામાં આવ્યું હોય, તો એજન્ટ સતત માનવીય દેખરેખ વિના ટ્રેક પર રહે છે, અને રાતોરાત કાચા હેતુને તૈયાર આઉટપુટમાં ફેરવી દે છે.
તે વચન સિદ્ધાંતમાં સુંદર રીતે કામ કરે છે. વ્યવહારમાં, મોટાભાગના એજન્ટ્સ પહેલેથી જ લૂપ કરે છે. તેઓ કોડ જનરેટ કરે છે, કમ્પાઈલર એરર્સ અથવા ટેસ્ટ નિષ્ફળતાઓ તપાસે છે, કોડમાં સુધારો કરે છે અને ફરીથી સ્યુટ રન કરે છે. આ મૂળભૂત ફીડબેક સાયકલ નવી નથી. જેનો સમર્થનકર્તાઓ અત્યારે આગ્રહ કરી રહ્યા છે તે કંઈક વધુ મહત્વાકાંક્ષી છે: એક આઉટર લૂપ (outer loop) જે માત્ર સિન્ટેક્સ એરર્સને જ નહીં, પરંતુ સમગ્ર કાર્યને સંચાલિત કરે. તે આઉટર લૂપ બનાવવી મુશ્કેલ છે, કારણ કે સોફ્ટવેર એન્જિનિયરિંગ ભાગ્યે જ નિશ્ચિત નિયમો ધરાવતી બંધ પ્રણાલી (closed system) હોય છે.
લૂપ ડિઝાઇન સમસ્યા (The Loop Design Problem)
પ્રોડક્ટના લક્ષ્યો અસ્તવ્યસ્ત હોય છે. તમે ભાગ્યે જ 'ડેફિનેશન ઓફ ડન' (definition of done) ની સંપૂર્ણ વ્યાખ્યા સાથે શરૂઆત કરો છો. મોટાભાગે, તમે જ્યારે નિર્માણ પ્રક્રિયામાં ઊંડા ઉતરો છો ત્યારે જ સાચું લક્ષ્ય શોધતા હોવ છો. વ્હાઇટબોર્ડ પર જે જરૂરિયાત સીધી અને સરળ લાગતી હતી, તે એવા એજ કેસીસ (edge cases) ધરાવતી હોઈ શકે છે જે સોલ્યુશનનો આખો આકાર બદલી નાખે છે. જ્યારે તમે એજન્ટને એક જડ લૂપમાં બાંધો છો, ત્યારે તે જડતા એક જવાબદારી (liability) બની જાય છે. લૂપ એવા લક્ષ્ય પર સતત પ્રહાર કરવાનું ચાલુ રાખે છે જે કદાચ ખોટું હોઈ શકે છે. તેનાથી પણ ખરાબ બાબત એ છે કે, એક લવચીક (flexible) લૂપ ક્યારેક જે આઉટપુટ તે બનાવી શક્યું હોય તેને મેચ કરવા માટે લક્ષ્યને શાંતિથી બદલી નાખતું દ્વારા ડેડલોક ઉકેલે છે. આમાંથી એકપણ પરિણામ ઉપયોગી નથી. એક કમ્પ્યુટિંગ પાવર વેડફે છે; બીજું આત્મવિશ્વાસ સાથે કચરો (garbage) મોકલે છે.
વધુ ઊંડી સમસ્યા સ્પેસિફિકેશન ખર્ચ (specification cost) ની છે. જો તમે ઈચ્છો છો કે લૂપ બિન-નિરીક્ષિત (unsupervised) રીતે ચાલે, તો તમારે એવી સ્પેસિફિકેશન લખવી પડશે જે લગભગ બધું જ અપેક્ષિત હોય. એજન્ટે બરાબર શું બદલવું જોઈએ? કયું હાલનું વર્તન પવિત્ર છે અને તેને જાળવી રાખવું આવશ્યક છે? કઈ ચોક્કસ પરિસ્થિતિઓમાં એજન્ટે પુનરાવર્તન કરવાનું બંધ કરવું જોઈએ? કયા જોખમો સ્વીકાર્ય છે, અને કયા આડઅસરો તાત્કાલિક વિરામ લાવવા જોઈએ? તે દસ્તાવેજ લખવામાં એજન્ટ સાથે બેસીને રીઅલ-ટાઇમમાં કાર્ય કરવા કરતાં વધુ સમય લાગી શકે છે. તમે ઓટોમેશન માટે મોટો પૂર્વ-ખર્ચ (heavy upfront tax) ચૂકવી રહ્યા છો, જેનો ફાયદો ત્યારે જ થાય છે જો વેરિફિકેશન (ચકાસણી) એ કામ કરવા કરતાં નોંધપાત્ર રીતે સસ્તું હોય.
લૂપ્સ ખરેખર ક્યાં ઉપયોગી બને છે (Where Loops Actually Earn Their Keep)
તેનો અર્થ એ નથી કે લૂપ એન્જિનિયરિંગ નકામું છે. તેનો અર્થ એ છે કે તે એક વિશિષ્ટ સાધન છે, કોઈ સાર્વત્રિક વ્યૂહરચના નથી. લૂપ્સ ત્યારે ચમકે છે જ્યારે વેરિફિકેશન ખર્ચ વધતો જાય અને સફળતાના માપદંડો સ્પષ્ટ હોય. ત્રણ જગ્યાઓ છે જ્યાં આ વાત સાચી ઠરે છે.
રૂટિન મિકેનિકલ કામ. એવા કાર્યો વિશે વિચારો જે સિનિયર એન્જિનિયર્સને નિવૃત્ત થવા મજબૂર કરે છે: ચોક્કસ ક્રમમાં એપ્લિકેશન્સ શરૂ કરવી, દરેક તબક્કાની પુષ્ટિ કરવા માટે ડિપ્લોયમેન્ટ UI પર ક્લિક કરવું, રિલીઝ પછી જાણીતા એરર સ્ટ્રિંગ્સ માટે લોગ્સ ગ્રેપ (grepping logs) કરવા, અથવા કન્ફિગરેશન ફાઇલ તમામ યોગ્ય નોડ્સ પર લખવામાં આવી છે તેની ચકાસણી કરવી. આ પગલાં મનુષ્યો માટે કંટાળાજનક છે પરંતુ વેરિફિકેશન માટે તુચ્છ છે. એક લૂપ પ્રક્રિયાનું ધ્યાન રાખી શકે છે, દરેક રીસ્ટાર્ટ પછી હેલ્થ એન્ડપોઈન્ટ્સ (health endpoints) તપાસી શકે છે અને જોખમના પ્રથમ સંકેત પર રોલબેક (roll back) કરી શકે છે. માનવી હજુ પણ રોલઆઉટ પ્લાન વ્યાખ્યાયિત કરે છે. લૂપ ફક્ત રાત્રે બે વાગ્યે મશીનની ધીરજ સાથે તેનો અમલ કરે છે.
માપી શકાય તેવા ઓપ્ટિમાઇઝેશન લક્ષ્યો. જ્યારે સફળતા એક આંકડો હોય, ત્યારે લૂપ્સ અત્યંત અસરકારક હોય છે. p99 લેટન્સી (latency) ને 150 મિલિસેકન્ડથી નીચે લાવો. મેમરી ફૂટપ્રિન્ટમાં વીસ ટકા ઘટાડો કરો. પાયથોનમાંથી રસ્ટમાં હોટ પાથ (hot path) માઇગ્રેટ કરો અને ખાતરી કરો કે તમામ હાલના યુનિટ ટેસ્ટ હજુ પણ પાસ થાય છે. લૂપ એક ફેરફાર જનરેટ કરી શકે છે, તેનું બેન્ચમાર્ક કરી શકે છે, જે ફેરફારથી પરિણામ સુધર્યું હોય તેને રાખી શકે છે અને બાકીનાને કાઢી નાખે છે. કારણ કે વેરિફિકેશન ઓટોમેટેડ છે અને સર્ચ સ્પેસ મોટી છે, મેન્યુઅલ રિવ્યુનો વધતો ખર્ચ લૂપ વિના આ કામને અવ્યવહાર્ય બનાવશે. લક્ષ્ય નિશ્ચિત છે. માર્ગ અજ્ઞાત છે. તે શ્રેષ્ઠ સ્થિતિ છે.
ઓપરેશનલ પ્લેબુક્સ. ઇન્સિડન્ટ રિસ્પોન્સ (Incident response) અને સપોર્ટ ટિકિટો ઘણીવાર એવા પેટર્ન અનુસરે છે જે મનુષ્યોએ પહેલેથી જ સમજી લીધા હોય છે. પ્રોડક્શન એરરના ચોક્કસ પ્રકાર માટે હંમેશા ક્રેડેન્શિયલ રોટેટ કરવાની અને કેશ ક્લિયર કરવાની જરૂર હોય છે. સપોર્ટ રિક્વેસ્ટની એક કેટેગરી જ્યારે ત્રણ ચોક્કસ શરતો પૂરી થાય ત્યારે રિફંડ સાથે ઉકેલી શકાય છે. એક લૂપ તે ટ્રિગર્સ પર નજર રાખી શકે છે અને પ્લેબુકનો અમલ કરી શકે છે, અને જ્યારે પેટર્ન તૂટે ત્યારે જ એસ્કેલેટ કરી શકે છે. તે એ નક્કી નથી કરતી કે પ્લેબુક સાચી છે; તે માત્ર એ સ્કેલ અને ઝડપથી સુસંગતતા જાળવી રાખે છે જે ઓન-કોલ એન્જિનિયરો મેચ કરી શકતા નથી.
રેગ્યુલેટર્સ, રેફરન્સ-સેટર્સ નહીં (Regulators, Not Reference-Setters)
વર્તમાન ચર્ચાઓમાં એક મહત્વપૂર્ણ તફાવત ખૂટે છે. લૂપ્સ (Loops) એ નિયમનકારો છે. તેઓ સિસ્ટમને પૂર્વનિર્ધારિત લક્ષ્ય સાથે સુસંગત રાખે છે, જેમ કે થર્મોસ્ટેટ રૂમને 72 ડિગ્રી પર રાખે છે. પરંતુ થર્મોસ્ટેટ 72 ડિગ્રી પસંદ નથી કરતું. કોઈએ પહેલા એ નક્કી કરવું પડ્યું હતું કે તે યોગ્ય તાપમાન છે.
સોફ્ટવેરના સંદર્ભમાં, આનો અર્થ એ છે કે લૂપની અંદર રહેલો એજન્ટ (agent) આખો દિવસ બગ્સ (bugs) સુધારી શકે છે, ફંક્શન્સને રિફેક્ટર (refactor) કરી શકે છે અથવા પેરામીટર્સ (parameters) ટ્યુન કરી શકે છે. જોકે, તે એ નક્કી કરી શકતું નથી કે કયું ફીચર (feature) ખરેખર ગ્રાહકને મદદ કરે છે અથવા આગામી રિલીઝ પહેલાં કોઈ બગ સુધારવો યોગ્ય છે કે નહીં. તે પસંદગીઓ માટે બિઝનેસ સંદર્ભ, વપરાશકર્તાની મુશ્કેલીઓ અને વ્યૂહાત્મક પ્રાથમિકતા વિશે નિર્ણય લેવાની ક્ષમતાની જરૂર હોય છે. એજન્ટ્સ અમલ કરે છે. માણસો નિર્ણય લે છે. આ બંને વચ્ચે ગેરસમજ થવાથી ટીમો પાસે સુંદર રીતે ઓપ્ટિમાઇઝ કરેલી સિસ્ટમ્સ તો હોય છે, પરંતુ તે ખોટી સમસ્યાનો ઉકેલ લાવે છે.
લૂપ એન્જિનિયરિંગ (Loop engineering) ઉપયોગી છે, પરંતુ તે મર્યાદિત છે. તે તમને શિસ્ત અને ઝડપ સાથે મશીન ચલાવવામાં મદદ કરે છે. તે કયું મશીન બનાવવું, તે કોના માટે છે, અથવા માનવીય દ્રષ્ટિકોણથી સફળતા કેવી દેખાય છે તે નક્કી કરતું નથી. કયું ફીચર મહત્વનું છે, કયું જોખમ સ્વીકાર્ય છે, અને ક્યારે લક્ષ્ય પોતે બદલવાની જરૂર છે, તે નિર્ણય લેવાની જવાબદારી તમારી છે. એવા કામ માટે લૂપ્સ બનાવો જેને તમે આપમેળે ચકાસી શકો તેટલું સારી રીતે સમજો છો. બાકીની બધી બાબતોમાં તમારી જાતને ઇન-ચાર્જ રાખો.
આ લેખ મૂળરૂપે Isaac Hagoel દ્વારા “Loop Engineering Minus The Hype.” માં ચર્ચાયેલા વિચારો પર આધારિત છે. વધુ એન્જિનિયરિંગ ચર્ચાઓ માટે, Telegram પર અમારી લર્નિંગ કોમ્યુનિટીમાં જોડાઓ.