દર થોડા મહિને, ઉદ્યોગ એવા સોફ્ટવેર માટે એક નવો શબ્દ રચે છે જે કથિત રીતે પોતાની જાતે વિચારે છે. અત્યારે તે શબ્દ "Agentic AI" છે. વેન્ડર્સ તેને લેન્ડિંગ પેજ અને પિચ ડેક પર ઝડપથી મૂકી દે છે. પરંતુ જ્યાં સુધી સિસ્ટમ તમારા વાતાવરણ, તમારા ડેટા અને તમારી નિષ્ફળતાના મોડ્સ (failure modes) સાથે સામનો ન કરે ત્યાં સુધી લેબલ માત્ર માર્કેટિંગ કોપી છે. આ શબ્દ પોતે તમને સુરક્ષા, વિશ્વસનીયતા અથવા યોગ્યતા વિશે કંઈ જ કહેતો નથી.
હવે ફીચર લિસ્ટ વાંચવાનું બંધ કરી ક્ષમતાઓ (capabilities) માપવાનું શરૂ કરવાનો સમય આવી ગયો છે.
લેબલની સમસ્યા
સેલ્સ એન્જિનિયરો તમને 'એજન્ટિક' આર્કિટેક્ચરના પુરાવા તરીકે ડેશબોર્ડ્સ, મલ્ટી-મોડલ ડ્રોપડાઉન મેનૂ અને મોબાઈલ એક્સેસ બતાવશે. તે ઇન્ટરફેસના વિકલ્પો છે, વર્તણૂકની ખાતરી નથી. એક પ્રોડક્ટ અત્યાધુનિક દેખાઈ શકે છે અને છતાં API ટાઈમઆઉટ પછી જ્યારે તેને યોજના સુધારવાની જરૂર પડે ત્યારે તે તૂટી શકે છે.
મહત્વનું એ છે કે શું સિસ્ટમ ખરેખર એક સ્વાયત્ત એજન્ટ (autonomous agent) ની જેમ વર્તે છે. શું તે કામને પગલાંઓમાં વિભાજિત કરે છે? શું તે કડક મર્યાદાઓની અંદર વાસ્તવિક સિસ્ટમોને સ્પર્શે છે? જ્યારે કંઈક બગડે છે, ત્યારે શું તે અનુકૂલન સાધે છે, કે તે ફક્ત નિષ્ફળ જાય છે અને રાહ જુએ છે? જ્યાં સુધી તમે તમારા સ્ટેક (stack) ને અનુરૂપ પુરાવા સાથે આ પ્રશ્નોના જવાબ ન આપો ત્યાં સુધી, તમે કોઈ પ્રોડક્ટ નહીં પણ માત્ર એક ખ્યાલ (concept) ખરીદી રહ્યા છો.
પાંચ ક્ષમતા પરીક્ષણો જે ખરેખર મહત્વના છે
હું દરેક એજન્ટિક દાવાને પાંચ ચોક્કસ ક્ષમતાઓ સામે ચકાસું છું. દરેક માટે, હું એક સરળ પ્રશ્ન પૂછું છું: શું આ વર્તણૂક દસ્તાવેજીકૃત છે, પાયલોટમાં ચકાસાયેલ છે, અથવા હજુ અજ્ઞાત છે? 'અજ્ઞાત' એ ડિફોલ્ટ છે. તેનાથી વિપરીત સાબિત કરવાની જવાબદારી પ્રોડક્ટ પર છે.
Planning (આયોજન). શું સિસ્ટમ અસ્પષ્ટ લક્ષ્યને ક્રમબદ્ધ, ચકાસી શકાય તેવા પગલાંઓમાં વિભાજિત કરે છે? કોઈપણ વ્યક્તિ ટુ-ડુ લિસ્ટ બનાવી શકે છે. સાચી કસોટી "આ ક્વાર્ટરમાં અમારો ક્લાઉડ ખર્ચ પંદર ટકા ઘટાડો કરો" જેવા જટિલ ઉદ્દેશ્યને સંભાળવામાં છે. એક સાચો એજન્ટ વર્તમાન વપરાશનું ઓડિટ કરે છે, નિષ્ક્રિય સંસાધનોને ઓળખે છે, યોગ્ય કદ (rightsizing) માટેની ભલામણો તૈયાર કરે છે અને યોગ્ય ક્રમમાં ફેરફાર વિનંતીઓનું શેડ્યૂલ બનાવે છે. જો તે તમને પાંચ મુદ્દાઓનો સામાન્ય નિબંધ આપે અને કામ પૂરું થયું કહે, તો તે આયોજન નથી. તે માત્ર સારાંશ (summarizing) છે.
Tools (સાધનો). શું તે નિર્ધારિત વ્યાપ (scope) ની અંદર વાસ્તવિક સિસ્ટમો પર કામ કરે છે? એક આકર્ષક ડેમોમાં મોક (mock) API ને કોલ કરવું સરળ છે. લિસ્ટ-પ્રિવિલેજ ક્રેડેન્શિયલ્સ સાથે તમારા પ્રોડક્શન CRM માં પ્રમાણિત થવું, રેકોર્ડ લખવો અને ટ્રાન્ઝેક્શન લોગ કરવું અઘરું છે. તમારે ચોક્કસપણે જાણવાની જરૂર છે કે તે કઈ સિસ્ટમોને સ્પર્શે છે, તેની પાસે કઈ કી (keys) છે અને તેની અસરનો વ્યાપ (blast radius) ક્યાં સમાપ્ત થાય છે. વ્યાપ મર્યાદિત હોવો જોઈએ. જો એજન્ટ પાસે ડિફોલ્ટ રીતે પ્રોડક્શનમાં લખવાની (write access) પરવાનગી હોય, તો તમારી પાસે એજન્ટ નથી. તમારી પાસે એક જવાબદારી (liability) છે.
Correction (સુધારો). શું તે નિષ્ફળતા પછી તેનું આગલું પગલું બદલે છે? અહીં મોટાભાગના પ્રોટોટાઇપ્સ નિષ્ફળ જાય છે. જ્યારે ત્રીજું પગલું 503 એરર અથવા સ્કીમા મિસમેચ (schema mismatch) આપે છે, ત્યારે શું એજન્ટ અનંત લૂપમાં ફસાય છે, સફળતાનો ખોટો સંદેશ (hallucinate) આપે છે, કે તેનો માર્ગ બદલે છે? સાચો સુધારો એટલે નિષ્ફળતાનું નિરીક્ષણ કરવું, વર્કફ્લોના બાકીના ભાગનું ફરીથી આયોજન કરવું અને મર્યાદાઓ ગુમાવ્યા વિના નવો માર્ગ અમલમાં મૂકવો. આશાવાદમાં લપેટાયેલું રીટ્રાય લૂપ (retry loop) એ સુધારો નથી.
Context (સંદર્ભ). શું તે દરેક પગલામાં મર્યાદાઓને સક્રિય રાખે છે? માત્ર મેમરી પૂરતી નથી. જો પ્રથમ પગલું "પાંચસો ડોલરના બજેટથી વધુ ન કરો" અથવા "EU ગ્રાહક ડેટાને બાકાત રાખો" જેવો કડક નિયમ સ્થાપિત કરે છે, તો પ્રોમ્પ્ટ સંદર્ભ બદલાવાને કારણે સાતમા પગલામાં તે મર્યાદાને અવગણી શકાય નહીં. આ નિયમો પાલન (compliance), બ્રાન્ડ વોઈસ, મંજૂરી પદાનુક્રમ (approval hierarchies) અને એક્સેસ કંટ્રોલને લાગુ પડે છે. સંદર્ભ જાળવી રાખવો એ એવું ક્ષેત્ર છે જ્યાં લોંગ-કોન્ટેક્સ્ટ મોડલ્સ અને ક્લાસિકલ સ્ટેટ મેનેજમેન્ટનો સુમેળ થવો જોઈએ.
Oversight (દેખરેખ). શું કોઈ માણસ પ્રક્રિયાને રોકી શકે છે અથવા ફરી શરૂ કરી શકે છે? તમારે ગ્રેન્યુલર (granular) સર્કિટ બ્રેકર્સની જરૂર છે, માત્ર વર્ચ્યુઅલ મશીન પર કિલ સ્વિચની નહીં. શું કોઈ બીજા પગલા પછી યોજનાનું નિરીક્ષણ કરી શકે છે અને ત્રીજા પગલાને મંજૂરી આપી શકે છે? જો કોઈ બાહ્ય નિર્ભરતા (external dependency) નિષ્ફળ જાય, તો શું કોઈ માણસ તેને સુધારી શકે છે અને સ્ટેટ (state) ગુમાવ્યા વિના વર્કફ્લો ફરી શરૂ કરી શકે છે? દેખરેખ એ આપત્તિ આવ્યા પછી તમે વાંચતા હોવ તેવો ઓડિટ લોગ નથી. તે હસ્તક્ષેપ માટેની એક જીવંત પદ્ધતિ છે.
પુરાવા ચેકબોક્સ કરતા વધુ મહત્વના છે
ડેમો એ વિશ્વસનીયતાનો દર નથી. વેન્ડર સરખામણી શીટ પરનું ચેકબોક્સ એ પુરાવો નથી. જ્યારે એક એકાઉન્ટ એક્ઝિક્યુટિવ કહે છે કે પ્રોડક્ટ "ટેસ્ટ નિષ્ફળતા પછી સુધારે છે," ત્યારે તમારું આગલું પગલું એવિડન્સ કાર્ડ (evidence card) માંગવાનું હોવું જોઈએ.
એવિડન્સ કાર્ડ ચેકબોક્સને ચોકસાઈ સાથે બદલે છે. તે આ મુજબ દેખાય છે:
- ક્ષમતા (Capability): સુધારો (Correction)
- દાવો (Claim): ટેસ્ટ નિષ્ફળતા પછી સુધારે છે
- પુરાવો (Evidence): પેન્ડિંગ કંટ્રોલ્ડ ફિક્સ્ચર (Pending controlled fixture)
- માલિક (Owner): ડેવલપર-એક્સપિરિયન્સ ટીમ (Developer-experience team)
- અટકાવો જો (Stop if): સુધારો મંજૂર કરેલા ઇન્ટરફેસને બદલે
આ ફોર્મેટ સ્પષ્ટતા લાવે છે. તે માર્કેટિંગના દાવાઓને પુરાવાથી અલગ કરે છે. તે માલિકી (ownership) સોંપે છે જેથી જ્યારે એજન્ટ તેના સુધારાના પ્રયાસ દરમિયાન મંજૂર કરેલા ઇન્ટરફેસને તોડી નાખે, ત્યારે તમને ખબર હોય કે કઈ ટીમને જાણ કરવામાં આવશે. માલિક વગર, કોઈ જવાબદારી નથી. સ્ટોપ કંડિશન્સ (અટકવાની શરતો) વગર, કોઈ સુરક્ષા રેલિંગ નથી.
કોઈપણ પાયલોટ શરૂ કરતા પહેલા, ત્રણ બાબતો લેખિતમાં વ્યાખ્યાયિત કરો. પ્રથમ, તમારા કાર્યો (tasks). આ વાસ્તવિક બિઝનેસ લોજિકમાંથી હોવા જોઈએ, સિન્થેટિક બેન્ચમાર્કમાંથી નહીં. બીજું, તમારા નિષ્ફળતાના પરીક્ષણો (failure tests). રન દરમિયાન API key રદ કરો, ખોટો (malformed) JSON પ્રતિસાદ ઇન્જેક્ટ કરો, અથવા અપેક્ષિત લેટન્સી (latency) બમણી કરો. ત્રીજું, તમારી સ્ટોપ કંડિશન્સ (અટકવાની શરતો). આ આપમેળે (automatic) હોવી જોઈએ, કોઈ મેન્યુઅલ પેનિક બટન નહીં જેના પર તમે આશા રાખો કે કોઈ તેને નોંધશે.
વેન્ડરના દાવાઓની તપાસ કેવી રીતે કરવી
OpenAI સૂચવે છે કે એજન્ટ્સને પાંચ ઘટકોની જરૂર છે: models, tools, instructions, guardrails, અને human intervention. તમે આ યાદીને વેન્ડર્સને પ્રશ્નો પૂછવા માટેના શબ્દભંડોળ તરીકે ઉપયોગ કરી શકો છો, તેમના ચોક્કસ આર્કિટેક્ચરને અપનાવ્યા વિના.
પૂછો કે કયું model માત્ર જનરેશનને બદલે પ્લાનિંગ સંભાળે છે. પૂછો કે કયા tool પરમિશન હાર્ડકોડેડ છે અને કયા ડાયનેમિક છે. પૂછો કે guardrails ક્યાં લાગુ કરવામાં આવે છે, prompt layer માં કે orchestration engine માં. પૂછો કે શું human intervention એ બિલ્ટ-ઇન ચેકપોઈન્ટ છે કે એજન્ટ તમારા ડેટાબેઝને બગાડી નાખ્યા પછી મોકલવામાં આવતો પોસ્ટ-મોર્ટમ ઇમેઇલ છે. તમે OpenAI ના stack માટે શોપિંગ કરી રહ્યા નથી. તમે બીજાના ફ્રેમવર્કમાં રહેલી ખામીઓને ખુલ્લી પાડવા માટે તેમના ફ્રેમવર્કનો ઉપયોગ કરી રહ્યા છો.
MonkeyCode એક ઓપન-સોર્સ માર્ગ અને મફત ક્લાઉડ વર્ઝન ઓફર કરે છે. આ સંયોજન પાયલોટ શરૂ કરવાનું સસ્તું બનાવે છે. પરંતુ સસ્તું એન્ટ્રી એટલે પ્રમાણિત સફળતા નથી. સિસ્ટમના અજાણ્યા ભાગો ત્યાં સુધી અજાણ્યા રહે છે જ્યાં સુધી તમે તમારા પોતાના ઇન્ફ્રાસ્ટ્રક્ચર પર તમારા પોતાના કાર્યો ન ચલાવો. શૂન્ય-ડોલરની ટિકિટ તમને એવું વિચારવા માટે છેતરી ન દે કે મુશ્કેલ પ્રશ્નોના જવાબ મળી ગયા છે.
બજેટ બચાવતો ખરીદીનો નિયમ
એજન્ટિક પાયલોટને પ્રોડક્શન કમિટમેન્ટમાં વિસ્તારવા માટેનો મારો નિયમ સરળ છે. હું સ્કોપ અને બજેટ ત્યારે જ વધારું છું જ્યારે મહત્વપૂર્ણ ક્ષમતાઓનો પુરાવો હોય અને નિષ્ફળતા માટે સ્પષ્ટ માલિક (owner) હોય. રોડમેપ સ્લાઇડ નહીં. સપોર્ટ ટિકિટ ક્યુ (queue) નહીં. પુરાવા એટલે તમારા એન્વાયરમેન્ટના લોગ્સ (logs). માલિક એટલે એક નામના વ્યક્તિ જે તે ચોક્કસ નિષ્ફળતા માટે જવાબદાર હોય.
જો વેન્ડર તમને પુરાવો ન બતાવી શકે, અથવા જો તમારી આંતરિક ટીમ માલિક સોંપી ન શકે, તો તમે વિસ્તારવા માટે તૈયાર નથી. તમે પરીક્ષણ ચાલુ રાખવા માટે તૈયાર છો.
શું યાદ રાખવું: "Agentic" શબ્દ તમારા મૂલ્યાંકન માટે સ્ટાર્ટિંગ પિસ્તોલ છે. તે ફિનિશ લાઇન નથી. તેને વધુ મુશ્કેલ પ્રશ્નો પૂછવા, વધુ કડક પાયલોટ ચલાવવા અને તમારા પોતાના ક્ષેત્રમાં મહત્વના પુરાવા માંગવા માટેના પ્રોમ્પ્ટ તરીકે ગણો. જો પ્રોડક્ટ તમારી શરતો પર, તમારી નિષ્ફળતાઓ સાથે, પાંચ ક્ષમતા પરીક્ષણો પાસ કરી શકતી નથી, તો તે ખરેખર એજન્ટિક નથી. તે માત્ર બીજો એક ડેમો છે.
Source: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h
વૈકલ્પિક લર્નિંગ કોમ્યુનિટી: https://t.me/GyaanSetuAi