તમારી એજન્ટ-આધારિત સિસ્ટમમાં નિર્ણયો કેવી રીતે અને ક્યાં લેવાય છે, તે કાળજીપૂર્વક વિચારવું મહત્વપૂર્ણ છે.
વધુ નિર્ણયો LLM પર છોડવાથી સિસ્ટમ વધુ કાર્યો માટે ઉપયોગી બની શકે છે, પરંતુ તેનાથી ઝડપ, વિશ્વસનીયતા અને મજબૂતાઈ ઘટી શકે છે.
શક્ય હોય ત્યાં નિર્ણય લેવાની પ્રક્રિયાનો શક્ય તેટલો ભાગ LLMમાંથી કાઢીને સ્પષ્ટ સોફ્ટવેર કોડમાં મૂકો. ખાસ કરીને ઉચ્ચ જોખમવાળા અને ઉત્પાદન કાર્યપ્રવાહો માટે આ સાચું છે.
LLM-આધારિત એજન્ટ સિસ્ટમ બનાવતી વખતે, તમારે લેવાતા સૌથી મહત્વપૂર્ણ નિર્ણયોમાંનો એક એ છે કે નિર્ણય પ્રક્રિયાનો કેટલો ભાગ LLM મોડલમાં રાખવો અને કેટલો સ્પષ્ટ સોફ્ટવેરમાં.
આ પસંદગીને સમજવા માટે આપણે તેને નીચેના અભિગમો વચ્ચેના વ્યાપ તરીકે જોઈ શકીએ છીએ:
રાઉટર-આધારિત આર્કિટેક્ચર કોડમાં ક્રમ અને તર્ક સ્પષ્ટ રીતે નિર્ધારિત કરે છે, જેથી મર્યાદિત ક્ષેત્રનાં કાર્યો માટે પરીક્ષણક્ષમતા, અનુમાનક્ષમતા અને મજબૂતાઈ સુનિશ્ચિત થાય છે. આને ‘કાર્યપ્રવાહ એજન્ટ’ પણ કહેવાય છે.
ઓર્કેસ્ટ્રેટર એજન્ટ કુદરતી ભાષાના પ્રોમ્પ્ટ વડે કાર્યપ્રવાહ ગતિશીલ રીતે નક્કી કરવા વિશાળ ભાષા મોડલ (LLM) પર આધાર રાખે છે. જ્યાં પૂર્વનિર્ધારિત તર્ક અપૂરતો કે અશક્ય હોય એવી મુક્ત પ્રકારની ક્રિયાપ્રતિક્રિયાઓ માટે તે આદર્શ છે.
ઉચ્ચ જોખમવાળા ઉત્પાદન કાર્યપ્રવાહો માટે અમે સામાન્ય રીતે વધુ રાઉટર-આધારિત સુવિધાઓ વાપરવાની અને લવચીક, સામાન્ય હેતુની વાતચીત માગતી એપ્લિકેશનો માટે ઓર્કેસ્ટ્રેટર રાખવાની ભલામણ કરીએ છીએ.
રાઉટર-આધારિત આર્કિટેક્ચર
રાઉટર એજન્ટ સિસ્ટમો:
કોડ અથવા સોફ્ટવેર દ્વારા નિર્ણયનો પ્રવાહ સ્પષ્ટ રીતે નક્કી કરે છે અને સોફ્ટવેર કયો માર્ગ લે તે નક્કી કરવા LLMનો ઉપયોગ કરે છે.
સ્પષ્ટ અને અનુમાનિત માર્ગો હોવાથી તે પરંપરાગત સોફ્ટવેર સિસ્ટમોની વધુ નજીક છે અને વધુ સુસંગત પરિણામ આપે છે.
ચોક્કસ રીતે વ્યાખ્યાયિત થઈ શકે તેવા કાર્યો માટે આદર્શ છે.
નીચે ‘રાઉટર અભિગમ’ વાપરતા વિમાન બુકિંગ ચેટબોટ એજન્ટનું સરળ ઉદાહરણ છે. LLM ત્રણ સંભવિત વિકલ્પોમાંથી પ્રશ્નનો આશય વર્ગીકૃત કરવામાં મદદ કરે છે, પરંતુ અંતે આપણું સોફ્ટવેર જ આ આશયને નમૂનારૂપ ટેક્સ્ટ જવાબ સાથે જોડે છે. LLM પર ખૂબ નિયંત્રણ હોવાથી વપરાશકર્તાને વધુ સુસંગત વર્તનનો અનુભવ થશે.
ઓર્કેસ્ટ્રેટર આર્કિટેક્ચર
રાઉટર સિસ્ટમથી વિપરીત, ઓર્કેસ્ટ્રેટર એજન્ટ સિસ્ટમો:
સોફ્ટવેરને બદલે કુદરતી ભાષાના પ્રોમ્પ્ટ દ્વારા તર્કનો પ્રવાહ નક્કી કરે છે. નોંધ: પ્રોગ્રામિંગ ભાષાની તુલનામાં કુદરતી ભાષા સ્વાભાવિક રીતે અસ્પષ્ટ અને લવચીક હોય છે. આ ગુણ સકારાત્મક પણ છે અને નકારાત્મક પણ, જેની ચર્ચા આગળ કરીશું. અમે આને ‘સૂચનને બદલે આશય’ તરીકે જોઈએ છીએ.
પ્રક્રિયા માટે અનેક વિકલ્પો આપી શકે છે, જેમાં અમલીકરણનો ક્રમ અને પદ્ધતિ LLM નક્કી કરે છે.
સોફ્ટવેરમાં સ્પષ્ટ રીતે વ્યાખ્યાયિત કરવા મુશ્કેલ હોય એવા નવા તાર્કિક માર્ગો ગતિશીલ રીતે બનાવી શકે છે.
આ અસ્પષ્ટતાથી અસંગત પરિણામો આવી શકે છે, પરંતુ જ્યારે તે યોગ્ય રીતે કામ કરે ત્યારે અનુભવ ‘જાદુઈ’ લાગી શકે છે.
નીચેના ઉદાહરણમાં એ જ સરળ વિમાનસેવા સમસ્યા માટે ઓર્કેસ્ટ્રેટર અભિગમ અપનાવાયો છે. કયો જવાબ યોગ્ય છે તે સોફ્ટવેરને નક્કી કરવા દેવાને બદલે નિર્ણય પ્રક્રિયા LLM સ્તરને સોંપવામાં આવે છે. અહીં બહુ-એજન્ટ સિસ્ટમ છે, જેમાં ‘મુખ્ય’ ઓર્કેસ્ટ્રેટર એજન્ટ વપરાશકર્તાના પ્રશ્નની પ્રાથમિક તપાસ કરીને તેને ખાસ વિમાનયાત્રા બદલવા માટે બનાવેલા એજન્ટને સોંપે છે અને અંતે તે વપરાશકર્તાને જવાબ આપે છે.
આ ઉદાહરણમાં LLM સ્તર વર્ગીકરણકાર, રાઉટર અને જવાબ લેખકની ભૂમિકા ભજવે છે. રાઉટર ઉદાહરણમાં તે માત્ર વર્ગીકરણકારની ભૂમિકા ભજવતું હતું અને બાકીનું કામ સોફ્ટવેર સંભાળતું હતું.
શક્ય હોય ત્યાં અમે રાઉટર-આધારિત અભિગમ વાપરવાની ભલામણ કરીએ છીએ, કારણ કે તેના નીચેના લાભો છે:
ઝડપ અને કાર્યક્ષમતા: બાહ્ય API પર આધારિત ઓર્કેસ્ટ્રેટરની તુલનામાં સ્થાનિક ગણતરીઓ વધુ ઝડપ આપે છે. ‘IF/ELSE’ તર્કને 400 અબજ પેરામીટર ધરાવતા LLM પ્રદાતાના મોડલમાંથી પસાર કરાવવા માટે ચૂકવણી કરવા કરતાં પાયથનમાં તેની પ્રક્રિયા કરવી ઘણી સસ્તી પણ છે.
પરીક્ષણક્ષમતા અને અનુમાનક્ષમતા: સ્થાપિત સોફ્ટવેર પદ્ધતિઓ દ્વારા ખામી શોધવી, પરીક્ષણ કરવું અને જાળવણી કરવી નોંધપાત્ર રીતે સરળ છે.
પારદર્શિતા અને વિશ્વસનીયતા: વર્તનમાં ઓછો ફેરફાર હોવાથી સમસ્યાનું નિદાન સરળ બને છે. એપ્લિકેશનના પ્રવાહનો મોટો ભાગ પણ LLMના અપારદર્શક અને અર્થઘટન ન થઈ શકે એવા વેઇટ્સને બદલે પારદર્શક, આવૃત્તિ-નિયંત્રિત સોફ્ટવેરમાં વ્યક્ત થાય છે.
રાઉટર અભિગમની ખામી એ છે કે તે કઠોર અને અલવચીક બની શકે છે તથા વધુ મુક્ત પ્રકારની સમસ્યાઓમાં સંઘર્ષ કરી શકે છે. હંમેશાં એકસરખો જવાબ આપતો ચેટબોટ તેના વપરાશકર્તાઓને કંટાળાજનક અથવા સ્થિર લાગી શકે છે.
ઓર્કેસ્ટ્રેટર રચનાઓમાં શક્તિશાળી ક્ષમતાઓ છે:
આયોજન: તે ગતિશીલ રીતે જવાબનું આયોજન કરી શકે છે.
સાધનની પસંદગી અથવા એજન્ટને સોંપણી: યોગ્ય સાધનો પસંદ કરે છે અથવા કાર્યો એજન્ટને સોંપે છે.
પરિણામોનું પુનરાવર્તિત સંયોજન: પરિણામો પર પુનરાવર્તિત રીતે કામ કરીને તેમને સર્જનાત્મક રીતે ફરી જોડે છે.
પૂર્ણતા નક્કી કરવી: જવાબને અંતિમ સ્વરૂપ આપવા પૂરતી માહિતી ક્યારે એકત્ર થઈ છે તે નક્કી કરે છે.
Pydantic-AI અથવા OpenAI Agents SDK જેવા માળખાનો ઉપયોગ કરવાથી ઓર્કેસ્ટ્રેશનનો અમલ સરળતાથી અને ઝડપથી થઈ શકે છે. તેથી તે પ્રદર્શન અથવા સંકલ્પનાના પ્રાયોગિક પુરાવા માટે ઉત્તમ છે.
આ અભિગમની ખામીઓ આ છે:
LLMનાં આયોજનનાં પગલાં અને ત્યાર પછીની ક્રિયાઓ સાચી અથવા યોગ્ય હશે તેની કોઈ ખાતરી નથી. રાઉટર સિસ્ટમમાં પણ આ જ સમસ્યા છે, પરંતુ તેના પર વધુ નિયંત્રણ હોવાથી તેનું વર્તન વધુ અનુમાનિત હોય છે.
સરળ અને સુવ્યાખ્યાયિત કાર્યો માટે બહુ-એજન્ટ સિસ્ટમની સંપૂર્ણ ક્ષમતાની જરૂર પડે તેવી શક્યતા ઓછી છે. ઉદાહરણ તરીકે, આપણા વિમાનસેવા એજન્ટના ઉદાહરણમાં વિમાનસેવા સહાય સિસ્ટમ સાથે વાત કરનાર વ્યક્તિ કદાચ મર્યાદિત પ્રકારનાં જ કામ કરવા માગતી હોય છે.
વધુ તર્ક LLMમાં સમાવાયેલો હોવાથી દુર્ભાવનાપૂર્ણ લોકો માટે જેલબ્રેક કરવું અથવા તેનો ગેરલાભ ઉઠાવવો ઘણો સરળ બને છે.
તે નિર્ણય પ્રક્રિયાને LLMમાં અમૂર્ત કરી દે છે અને તેથી તમારી સિસ્ટમને સમજવી મુશ્કેલ બને છે. જોકે Langfuse અથવા Braintrust જેવાં નિરીક્ષણ સાધનો આમાં આંશિક મદદ કરી શકે છે.
વાચક માટે નોંધ: મોડલની ક્ષમતા ઝડપથી બદલાઈ રહી છે, છતાં નીચેની બાબતો નજીકના ભવિષ્યમાં બદલાય તેવી શક્યતા ઓછી છે.
તમારી સમસ્યાનો વ્યાપ નક્કી કરો.
શું તમે ઇચ્છિત નિર્ણય તર્કને આલેખમાં સરળતાથી વ્યાખ્યાયિત કરી શકો છો?
શું તમારી એપ્લિકેશનમાં નિષ્ફળતા કે અનપેક્ષિત વર્તન બિલકુલ સ્વીકાર્ય નથી?
ઉપરના બેમાંથી કોઈ એક પ્રશ્નનો જવાબ ‘હા’ હોય તો રાઉટર સુવિધાઓ વધુ યોગ્ય હોવાનો સંકેત મળે છે.
શક્ય હોય ત્યાં સુધી અમે રાઉટર અભિગમ વાપરવાની ભલામણ કરીએ છીએ. સામાન્ય સિદ્ધાંત મુજબ, તમારી સિસ્ટમનો કોઈ ભાગ કોડમાં વ્યક્ત થઈ શકે તો તેને કોડમાં જ લખો. એટલે કે જરૂર ન હોય ત્યારે LLMનો અતિશય ઉપયોગ ન કરો.
આ અભિગમોની મર્યાદા આવી જાય ત્યારે ઓર્કેસ્ટ્રેટરના કેટલાક મુક્ત પ્રકારના લાભો નિયંત્રિત રીતે ફરી મેળવી શકાય છે. ઉદાહરણ તરીકે:
સાધનની પસંદગી અથવા એજન્ટને સોંપણી: શરતી શાખાઓ અથવા LLM વર્ગીકરણકારો દ્વારા સરળતાથી અમલ કરી શકાય છે.
પૂર્ણતા નક્કી કરવી: સરળ LLM વર્ગીકરણકારો જવાબ વપરાશકર્તાને આપતાં પહેલાં તે સંપૂર્ણ છે કે નહીં તે ચકાસી શકે છે.
જોકે કઠોર રાઉટર સિસ્ટમમાં ‘આયોજન’ અને ‘પરિણામોનું પુનરાવર્તિત સંયોજન’ નિઃસંદેહ વધુ મુશ્કેલ છે. તેથી કોઈ કાર્ય માટે આ ક્ષમતાઓ જરૂરી હોય, જે LLM વર્ગીકરણકાર અથવા અન્ય તર્કથી નક્કી થાય, ત્યારે અમે તમારી સિસ્ટમમાં ઓછા નિયંત્રણવાળી ઓર્કેસ્ટ્રેટર શાખા બનાવવાનું સૂચવીએ છીએ.
રાઉટર અને ઓર્કેસ્ટ્રેટર આર્કિટેક્ચર વચ્ચેની તમારી પસંદગી એપ્લિકેશનની સ્પષ્ટતા, જટિલતા અને ક્રિયાપ્રતિક્રિયાની શૈલીને અનુરૂપ હોવી જોઈએ. રાઉટર-આધારિત અભિગમ હાલમાં સ્પષ્ટ રીતે વ્યાખ્યાયિત કાર્યો માટે વિશ્વસનીયતા, કાર્યક્ષમતા અને સરળ પરીક્ષણની સુવિધા આપે છે. વ્યાપક અને વાતચીત-આધારિત ક્રિયાપ્રતિક્રિયાઓ માટે ઓર્કેસ્ટ્રેટર વધુ લવચીકતા આપે છે.
LLM વધુ વિકસિત થતાં આ અભિગમો વચ્ચેનું સંતુલન બદલાઈ શકે છે. ઉત્પાદન કાર્યભાર માટે અમે રાઉટર-આધારિત અથવા સંકર આર્કિટેક્ચર તરફ ઝૂકીએ છીએ અને ગતિશીલ, માનવસમાન સંવાદ માગતી મુક્ત પ્રકારની સમસ્યાઓ માટે ઓર્કેસ્ટ્રેટર રાખીએ છીએ.