જ્યારે Anthropic એ ૨૦૨૪ના અંતમાં Building Effective Agents પ્રકાશિત કર્યું, ત્યારે તેણે ઉદ્યોગ માટે કંઈક દુર્લભ કર્યું: એન્જિનિયરોને એક સમાન શબ્દભંડોળ આપ્યું. આર્ટિફિશિયલ જનરલ ઇન્ટેલિજન્સ વિશેના અન્ય કોઈ મેનિફેસ્ટોને બદલે, આ માર્ગદર્શિકાએ LLM સિસ્ટમ્સનું માળખું તૈયાર કરવા માટે છ સ્પષ્ટ પેટર્ન (patterns) ઓફર કરી. દોઢ વર્ષ પછી, ૨૦૨૬માં, પરિદ્રશ્ય સંપૂર્ણપણે અલગ દેખાય છે. Model Context Protocol એક સાર્વત્રિક ધોરણ બની ગયું છે. Claude એ નવી ક્ષમતાઓ મેળવી છે. મોટાભાગની સંસ્થાઓમાં હવે પ્રોડક્શનમાં ઓછામાં ઓછો એક એજન્ટ કાર્યરત છે. આ પૃષ્ઠભૂમિમાં, એ પૂછવું યોગ્ય છે કે શું તે છ પેટર્ન હજુ પણ મહત્વની છે, અથવા શું તેઓ ગયા વર્ષના મોડેલ વેટ્સ (model weights) ની સાથે આર્કાઇવમાં જઈ શકે છે.
જાણવા માટે મેં એક સાઇડ રિપોઝિટરીમાં લોકલ મોડેલ સામે તમામ છ પેટર્નનું પરીક્ષણ કર્યું. જવાબ છે, હા. તેઓ હજુ પણ ટકી રહી છે. પરંતુ એટલા માટે નહીં કે તેઓ અપરિવર્તનીય નિયમો છે. તેઓ એટલા માટે ટકી રહી છે કારણ કે છેલ્લા અઢાર મહિનાના પ્રોડક્શન અનુભવે આ ફ્રેમવર્કના મુખ્ય તર્કને સાબિત કર્યો છે.
આ ફ્રેમવર્કે ખરેખર આપણને શું આપ્યું
આ છ પેટર્ન ચોક્કસપણે યાદ રાખવા જેવી છે: Prompt Chaining, Routing, Parallelization, Evaluator-Optimizer, Orchestrator-Workers, અને Autonomous Agents. છેલ્લી પેટર્ન એessentally એક લૂપ છે જેમાં મોડેલ આયોજન કરે છે, કાર્ય કરે છે, અવલોકન કરે છે, અને જ્યાં સુધી કોઈ શરત પૂરી ન થાય ત્યાં સુધી આ પ્રક્રિયાનું પુનરાવર્તન કરે છે.
માર્ગદર્શિકા આવ્યા પહેલાં ઘણા એન્જિનિયરો પહેલેથી જ પ્રોમ્પ્ટ્સને ચેઈન કરી રહ્યા હતા અથવા વર્કર થ્રેડ્સને કાર્યો સોંપતા હતા. Anthropic એ જે આપ્યું તે હતું ટેક્સનોમી (taxonomy). એક વ્યક્તિ માટે જે "agent" હતું તે બીજી વ્યક્તિ માટે "workflow" હતું, અને ત્રીજી વ્યક્તિ માટે "multi-step tool call" હતું. આ માર્ગદર્શિકાએ આ અંધાધૂંધીને સ્પષ્ટ સીમાઓવાળા વિભાગોમાં વહેંચી દીધી. તેનાથી એકબીજાને સમજ્યા વગર ચર્ચા કરવાને બદલે, ટ્રેડ-ઓફ્સ (trade-offs) વિશે તર્કપૂર્ણ ચર્ચા કરવી શક્ય બની. અતિશયોક્તિ (hype) માં ડૂબેલા આ ક્ષેત્રમાં, સ્પષ્ટ ભાષા એક પ્રકારનું ઈન્ફ્રાસ્ટ્રક્ચર છે.
ઉદ્યોગે તેની આસપાસ નહીં, પણ તેની ઉપર નિર્માણ કર્યું
૨૦૨૬ સુધીમાં, આ શ્રેણીઓ ટીમો સિસ્ટમ કેવી રીતે ડિઝાઇન કરે છે તેમાં વણાઈ ગઈ છે. Anthropic હજુ પણ તેમના એકેડેમી કોર્સમાં તે શીખવે છે. રિસર્ચ પેપર્સ અને એન્જિનિયરિંગ બ્લોગ્સ હજુ પણ નવા આર્કિટેક્ચર્સનું વર્ણન કરવા માટે આ જ છ વિભાગોનો ઉપયોગ કરે છે. જે વિષય દર ત્રણ મહિને પોતાનું સ્ટેક (stack) બદલી નાખતો હોય, તેના માટે આ પ્રકારનું લાંબુ આયુષ્ય અસામાન્ય છે.
તેનું કારણ સરળ છે. ઉદ્યોગે આ ફ્રેમવર્કને બદલ્યું નથી, પરંતુ તેના પર નિર્માણ કર્યું છે. MCP જેવા નવા સાધનો અને નવા Agent Skills ધોરણો પ્લમ્બિંગ (plumbing) તરીકે કાર્ય કરે છે. તેઓ મોડેલને ડેટાબેઝ સાથે જોડવાનું, ટૂલ એક્સપોઝ કરવાનું અથવા સ્ટેટ (state) મેનેજ કરવાનું સરળ બનાવે છે. પરંતુ તેઓ ઓર્કેસ્ટ્રેટરને બદલે રાઉટરનો ઉપયોગ ક્યારે કરવો તેના તર્કને બદલતા નથી. વધુ સારું પાઇપિંગ ફ્લોર પ્લાનને ફરીથી લખતું નથી.
૨૦૨૬ના પ્રોડક્શન ડેટા આ વાતની પુષ્ટિ કરે છે. સૌથી સામાન્ય ડિપ્લોયમેન્ટ પેટર્ન હજુ પણ માનવીય સમીક્ષા સાથે જોડાયેલ સિંગલ ટૂલ-યુઝ કોલ છે. બીજી સૌથી સામાન્ય પેટર્ન એક વ્યક્તિને આપેલ સિંગલ હેન્ડઓફ સાથેનું મલ્ટી-સ્ટેપ વર્કફ્લો છે. બંને Prompt Chaining અને Routing ના સીધા વંશજો છે. લાઈવ સિસ્ટમ્સમાં સંપૂર્ણ ઓટોનોમસ લૂપ્સ અપવાદ છે, નિયમ નહીં.
સંયમે બજાર જીત્યું
મૂળ માર્ગદર્શિકાની શ્રેષ્ઠ સલાહ એ હતી જે ૨૦૨૪માં સૌથી વધુ અવગણવામાં આવી હતી: જે પેટર્ન કામ કરે છે તેનો સૌથી સરળ ઉપયોગ કરો. જો હાર્ડકોડેડ પાથથી કામ થઈ જતું હોય, તો સંપૂર્ણ ઓટોનોમસ એજન્ટ ડિપ્લોય કરશો નહીં.
બજારએ આ વાતને આખરે સ્વીકારી લીધી છે. મોટાભાગના એજન્ટ પાયલોટ હજુ પણ નિષ્ફળ જાય છે, અને તેઓ તે જ અનુમાનિત કારણોસર નિષ્ફળ જાય છે. ટીમો એબસ્ટ્રેક્શન પર એબસ્ટ્રેક્શનનું સ્તર એટલું વધારી દે છે કે કોઈ નિર્ણયની સીમા (decision boundary) શોધી શકતું નથી. જ્યારે સિસ્ટમ ડ્રિફ્ટ થાય છે, ત્યારે ડીબગિંગ એ પુરાતત્વશાસ્ત્ર (archaeology) જેવું બની જાય છે. જે કંપનીઓ પ્રોડક્શનમાં સફળ થઈ છે તેઓએ સંયમ બતાવ્યો છે. તેઓએ સિંગલ-ટર્ન ટૂલ યુઝને પ્રાથમિકતા આપી. તેમણે રાઉટિંગ લેયર ત્યારે જ ઉમેર્યું જ્યારે સિંગલ પ્રોમ્પ્ટ અસંગત સાબિત થયો. તેમણે સ્વાયત્તતાને (autonomy) ઉજવણી કરવા જેવી વિશેષતા તરીકે નહીં, પરંતુ સાબિત કરવા જેવી જવાબદારી તરીકે જોવી.
આ મહત્વાકાંક્ષા વિરુદ્ધની દલીલ નથી. આ સંયોજન (composition) માટેની દલીલ છે. પેટર્ન ત્યારે શ્રેષ્ઠ રીતે કામ કરે છે જ્યારે તમે મેનૂમાંથી સૌથી જટિલ વિકલ્પ પસંદ કરવાને બદલે જાણીજોઈને તેમને જોડો છો.
જ્યાં ખામીઓ દેખાવા લાગે છે
આ ફ્રેમવર્ક દરેક સમસ્યાનો ઉકેલ નથી. જે ક્ષણે તમે પ્રોટોટાઇપ સ્ટેજ છોડો છો, તે ક્ષણે કેટલીક કડક મર્યાદાઓ સામે આવે છે.
ઉચ્ચ-આવર્તન (high-frequency) અને ઓછી-કિંમત ધરાવતા કાર્યો માટે, deterministic code હજુ પણ શ્રેષ્ઠ છે. જ્યારે pandas તેને મિલિસેકન્ડોમાં અને કોઈપણ ભ્રમ (hallucination) વગર કરી શકે છે, ત્યારે LLM એ CSV કોલમને નોર્મલાઈઝ (normalizing) કરવી જોઈએ નહીં. જો તમે સ્પષ્ટ મૂલ્યાંકન લક્ષ્ય (evaluation goal) વ્યાખ્યાયિત કરી શકતા નથી, તો autonomous loops ટાળો. સ્પષ્ટ stopping condition વગર, મોડેલ ત્યાં સુધી iterate કરતું રહેશે જ્યાં સુધી તે અટકવા માટે કોઈ કારણ ન બનાવી લે. બાહ્ય આધાર (external grounding) જરૂરી હોય તેવા ઉચ્ચ-જોખમવાળા નિર્ણયો માટે, માત્ર મોડેલના આંતરિક જ્ઞાન પર આધાર રાખશો નહીં. અને ડેટા રિટ્રાઇવલ (data retrieval) માં આવતા અવરોધો (bottlenecks) પર ધ્યાન આપો. કોઈપણ પેટર્ન જે vector search અથવા બાહ્ય APIs પર આધારિત છે, તે ત્યારે અટકી શકે છે જો તમારું ડેટાબેઝ ધીમું હોય અથવા તમારું context window બિનજરૂરી chunks થી ભરાઈ ગયું હોય.
આ કાલ્પનિક edge cases નથી. આ એ મર્યાદાઓ છે જે એક કામ કરતા ડેમો અને વીકેન્ડ સુધી ટકી રહે તેવી સિસ્ટમ વચ્ચેનો તફાવત સ્પષ્ટ કરે છે.
એક કડક તપાસ અને એક ખોટી નિષ્ફળતા
મેં મારું ટેસ્ટ રિપોઝિટરી (test repository) બનાવતી વખતે આ ફ્રેમવર્કનું વ્યવહારુ મૂલ્ય શીખ્યું. હું Evaluator-Optimizer પેટર્ન અમલમાં મૂકી રહ્યો હતો. મારું ઇવેલ્યુએટર (evaluator) એક હાર્ડકોડેડ regex તરીકે શરૂ થયું હતું જે મોડેલના આઉટપુટમાં ચોક્કસ કીવર્ડ્સ સ્કેન કરતું હતું. મોડેલે એક સાચો અને તર્કબદ્ધ જવાબ આપ્યો હતો, જેમાં મેં જે ચોક્કસ શબ્દો શોધ્યા હતા તેના બદલે સમાનાર્થી શબ્દોનો ઉપયોગ થયો હતો. ઇવેલ્યુએટરે તેને નિષ્ફળતા તરીકે દર્શાવ્યું.
મોડેલ સાચું હતું. મારી તપાસ ખૂબ જ કડક હતી.
તેને સુધારવા માટે માત્ર શબ્દ સૂચિ વધારવા કરતાં વધુ કંઈક કરવું જરૂરી હતું. મેં ઇવેલ્યુએટરને જ LLM-આધારિત નિર્ણય પ્રક્રિયામાં બદલી નાખ્યું. તેનાથી વધારાના tokens અને થોડી વધુ મિલિસેકન્ડોનો ખર્ચ થયો, પરંતુ તેણે મૂલ્યાંકનને યોગ્ય સ્તરના abstraction પર પાછું લાવ્યું. પેટર્ન પોતે જ સચોટ હતી. મેં ફક્ત કાર્ય માટે ખોટી implementation પદ્ધતિ પસંદ કરી હતી. આ બરાબર એ પ્રકારની ભૂલ છે જેને રોકવા માટે આ ફ્રેમવર્ક બનાવવામાં આવ્યું છે. કેટલાક મૂલ્યાંકનો માટે કોડની જરૂર હોય છે. અન્ય માટે મોડેલની જરૂર હોય છે. ક્યારે શેની જરૂર છે તે જાણવું એ જ મુખ્ય હેતુ છે.
હવે તેનો ઉપયોગ કેવી રીતે કરવો
આ છ પેટર્નને શરૂઆત તરીકે ગણો, તેને અંતિમ નિયમ ન માનો. એક સિંગલ પ્રોમ્પ્ટથી શરૂઆત કરો. જો ઇનપુટના પ્રકારો વચ્ચે ગુણવત્તા અસંગત હોય, તો વિવિધ વિનંતીઓને વિશિષ્ટ પ્રોમ્પ્ટ્સ પર મોકલવા માટે એક routing layer ઉમેરો. જો તમારે નિર્ણય લેતા પહેલા અનેક સ્વતંત્ર દ્રષ્ટિકોણની જરૂર હોય, તો Parallelization નો ઉપયોગ કરો. જો કાર્ય મોટું અને વિભાજિત કરી શકાય તેવું હોય, તો Orchestrator-Workers અજમાવો. સંપૂર્ણ autonomous loop નો ઉપયોગ ત્યારે જ કરો જ્યારે સમસ્યાનું ક્ષેત્ર એટલું વિશાળ હોય કે તેને અગાઉથી મેપ કરી શકાય તેમ ન હોય અને જ્યારે તમારી પાસે વિશ્વસનીય