AI સંવાદમાં ખૂટતો એક મહત્વનો ઘટક
દરેક વ્યક્તિ AI એજન્ટ્સ વિશે વાત કરી રહી છે. કોઈપણ ટેક ફીડ સ્ક્રોલ કરો તો તમને ડઝનબંધ ડેમો જોવા મળશે જેમાં એક લાર્જ લેંગ્વેજ મોડેલ (LLM) ફ્લાઇટ બુક કરી રહ્યું છે, કોડ લખી રહ્યું છે, અથવા એક જ આકર્ષક સંવાદમાં સપોર્ટ ટિકિટોના જવાબ આપી રહ્યું છે. તેનો મૂળ સંદેશ સ્પષ્ટ લાગે છે: જો તમે વપરાશકર્તાને LLM સાથે જોડો છો, તો જાદુ થાય છે.
આ ભ્રમ પાંચ મિનિટના ડેમો માટે સુંદર રીતે કામ કરે છે. પરંતુ જે ક્ષણે વાસ્તવિક વપરાશકર્તાઓ, વાસ્તવિક ડેટા અને વાસ્તવિક નાણાં સામે આવે છે, ત્યારે આ ભ્રમ તૂટી પડે છે. પ્રોડક્શનમાં, સંબંધ ક્યારેય માત્ર User ↔ LLM હોતો નથી. તે User ↔ એક જટિલ સિસ્ટમ છે જેમાં LLM નો સમાવેશ થાય છે. તે સિસ્ટમનો એ ભાગ જેના વિશે કોઈ વાત કરતું નથી તે છે 'હાર્નેસ' (harness)—એવું માળખું જે મોડેલની આસપાસની દરેક વસ્તુને પસંદ કરે છે, રૂટ કરે છે, સુરક્ષિત કરે છે અને સંચાલિત (orchestrate) કરે છે. તેના વગર, તમારી પાસે પ્રોડક્ટ નથી. તમારી પાસે માત્ર એક પ્રોટોટાઇપ છે.
સાદું લૂપ (Simple Loop) કેમ નિષ્ફળ જાય છે
ડેમો એ એક નિયંત્રિત વાતાવરણ છે. ક્વેરીઝ ટૂંકી હોય છે, સંદર્ભ (context) મર્યાદિત હોય છે, અને જોખમ ઓછું હોય છે. ડેવલપર એક સિંગલ API કોલ કરે છે, એક સચોટ પ્રતિસાદ મેળવે છે, અને પ્રેક્ષકો તાળીઓ પાડે છે. પરંતુ પ્રોડક્શન અસ્તવ્યસ્ત હોય છે. વપરાશકર્તાઓ અસ્પષ્ટ ફોલો-અપ પ્રશ્નો પૂછે છે. થર્ડ-પાર્ટી API ટાઈમઆઉટ થાય છે. જે મોડેલે ગઈકાલે પરફેક્ટ JSON જનરેટ કર્યું હતું, તે અચાનક માર્કડાઉન (markdown) આપવા લાગે છે. કોન્ટેક્સ્ટ વિન્ડો ભરાઈ જાય છે. રેટ લિમિટ્સ (Rate limits) સૌથી ખરાબ સમયે લાગુ થઈ જાય છે.
એક કાચા (raw) પ્રોમ્પ્ટ-રિસ્પોન્સ લૂપ પાસે આમાંથી કોઈપણ સમસ્યાનો ઉકેલ હોતો નથી. તેને ખબર નથી હોતી કે આપેલ કાર્ય માટે કયા મોડેલ વેરિઅન્ટનો ઉપયોગ કરવો જોઈએ. તેને ત્રણ સ્ટેપ પહેલા શું થયું હતું તે યાદ નથી હોતું. તે નિષ્ફળ ગયેલા કોલને ફરીથી પ્રયાસ (retry) કરી શકતું નથી, ખર્ચ વધે ત્યારે વિનંતીઓને મર્યાદિત (throttle) કરી શકતું નથી, અથવા તમારા ડેટાબેઝમાં પહોંચતા પહેલા આઉટપુટને સેનિટાઇઝ (sanitize) કરી શકતું નથી. આ માત્ર 'એજ કેસિસ' (edge cases) નથી. તે વાસ્તવિક દુનિયાના સોફ્ટવેરના મુખ્ય લક્ષણો છે. તેમને હેન્ડલ કરવાનું કામ હાર્નેસનું છે.
હાર્નેસ (Harness) ખરેખર શું કરે છે
હાર્નેસને એન્જિનિયરિંગ લેયર તરીકે વિચારો જે એક લેંગ્વેજ મોડેલને માત્ર એક ચતુર ટેક્સ્ટ જનરેટરમાંથી એક વિશ્વસનીય સર્વિસ કમ્પોનન્ટમાં ફેરવે છે. તેની જવાબદારીઓ નક્કર અને બિન-આકર્ષક છે, અને તે જ કારણ છે કે તેને અવગણવામાં આવે છે.
આપેલ કાર્ય માટે મોડેલની પસંદગી. દરેક ઇન્ટરેક્શન માટે ઉપલબ્ધ સૌથી શક્તિશાળી ફાઉન્ડેશન મોડેલની જરૂર નથી હોતી. કેટલાક કાર્યો માટે શુદ્ધ તર્કશક્તિ (reasoning power) જોઈએ છે; અન્યને ફક્ત ઝડપ અને ઓછા ખર્ચની જરૂર હોય છે. એક સુવ્યવસ્થિત હાર્નેસ વિનંતીઓને બુદ્ધિપૂર્વક રૂટ કરે છે. ઉદાહરણ તરીકે, એક કસ્ટમર સપોર્ટ એજન્ટ આવતા મેસેજનો ઈન્ટેન્ટ (intent) વર્ગીકૃત કરવા માટે—રિફંડ વિનંતી વિરુદ્ધ શિપિંગ પ્રશ્ન—ઝડપી અને સસ્તું મોડેલ વાપરી શકે છે. જો ઈન્ટેન્ટ કોઈ જટિલ પોલિસી વિવાદ સૂચવે છે, તો હાર્નેસ તે કાર્યને વધુ શક્તિશાળી રીઝનિંગ મોડેલ પર મોકલે છે (escalates). જો વપરાશકર્તા ફક્ત ટ્રેકિંગ લિંક ઈચ્છતા હોય, તો હળવું (lightweight) મોડેલ તરત જ જવાબ આપે છે અને તમારો ખર્ચ (burn rate) નિયંત્રણમાં રહે છે.
ડેટા ફ્લોનું સંચાલન. વાસ્તવિક એપ્લિકેશન્સ શૂન્યાવકાશમાં કામ નથી કરતી. એક AI એજન્ટને ઘણીવાર વેક્ટર સ્ટોર (vector store) માંથી દસ્તાવેજો મેળવવા, CRM માં ક્વેરી કરવી, તાજેતરની યુઝર એક્ટિવિટી વાંચવી અને પછી તે બધું એક સુસંગત પ્રતિસાદમાં સંશ્લેષિત (synthesize) કરવાની જરૂર પડે છે. હાર્નેસ તે ઇન્જેશન (ingestion) નું સંચાલન કરે છે. તે યોગ્ય કોન્ટેક્સ્ટ ચંક્સ (context chunks) મેળવે છે, તે સુસંગતતા ગુમાવ્યા વિના ટોકન લિમિટ્સમાં સમાઈ જાય છે કે નહીં તે તપાસે છે, તેને મોડેલ માટે સ્ટ્રક્ચર કરે છે, અને પરિણામી આઉટપુટને ચેઇનમાં આગળના સિસ્ટમ પર મોકલે છે. આ સંચાલન વગર, મોડેલ કાં તો કોન્ટેક્સ્ટ વગરનું રહી જાય છે અથવા અવાજ (noise) માં ડૂબી જાય છે.
ભૂલોનું સંચાલન (Managing errors). LLMs એવી રીતે નિષ્ફળ જાય છે જે રીતે પરંપરાગત સેવાઓ નિષ્ફળ જતી નથી. તેઓ સ્ટ્રક્ચર્ડ આઉટપુટમાં ભ્રમ (hallucinate) પેદા કરે છે. તેઓ ખાલી કમ્પ્લીશન્સ રિટર્ન કરે છે. જે ક્ષણે અન્ડરલાઇંગ મોડેલ વર્ઝન સહેજ બદલાય છે, તે ફોર્મેટિંગ સૂચનાઓનું ઉલ્લંઘન કરે છે. હાર્નેસ આ નિષ્ફળતાઓને આશ્ચર્યને બદલે અપેક્ષિત વર્તન તરીકે ગણે છે. તે સ્કીમા (schemas) ને વેલિડેટ કરે છે, ખોટા આઉટપુટને પકડે છે, એક્સપોનેન્શિયલ બેકઓફ (exponential backoff) સાથે રિટ્રાય લોજિક લાગુ કરે છે, અને જ્યારે મુખ્ય એન્ડપોઈન્ટ નિષ્ફળ જાય ત્યારે સેકન્ડરી પ્રોવાઈડર અથવા કેશ્ડ રિઝલ્ટનો ઉપયોગ કરે છે. જ્યારે બધું જ નિષ્ફળ જાય, ત્યારે તે પેઇડ કસ્ટમરને મૂર્ખતાભર્યો ડેટા આપવાને બદલે માનવ ઓપરેટર પાસે મોકલી દે છે.
સિસ્ટમની વિશ્વસનીયતા સુનિશ્ચિત કરવી. પ્રોડક્શનનો અર્થ છે એકસાથે ઘણા વપરાશકર્તાઓ (concurrent users), ખર્ચની મર્યાદા (cost caps), અને અનિશ્ચિત લેટન્સી (latency). હાર્નેસ રેટ લિમિટ્સ લાગુ કરે છે, કનેક્શન પૂલિંગનું સંચાલન કરે છે, અને સર્કિટ બ્રેકર્સ (circuit breakers) અમલમાં મૂકે છે જેથી એક ધીમો મોડેલ પ્રોવાઈડર તમારી સમગ્ર એપ્લિકેશનને જામ ન કરી દે. તે દરેક ઇન્ટરેક્શનને લોગ કરે છે જેથી તમે જાણી શકો કે કોઈ ચોક્કસ સેશન કેમ નિષ્ફળ ગયું, અને તે તમારા પ્રોમ્પ્ટ્સનું વર્ઝનિંગ કરે છે જેથી ડિપ્લોયમેન્ટ દરમિયાન ઓડિટ ટ્રેલ્સ વગર તમારા એજન્ટનું વ્યક્તિત્વ અચાનક બદલાઈ ન જાય.
સમાન મોડેલ, તદ્દન અલગ પરિણામો
આ એક એવી ઘટના સમજાવે છે જે ઘણા પ્રોડક્ટ ટીમોને મૂંઝવણમાં મૂકે છે. બે કંપનીઓ એક જ પ્રકારના ફાઉન્ડેશન મોડલથી શરૂઆત કરી શકે છે—એક જ વેટ્સ (weights), એક જ કોન્ટેક્સ્ટ વિન્ડો (context window), એક જ ટ્રેનિંગ કટઓફ—અને એવા અનુભવો આપી શકે છે જે એકબીજાથી સાવ અલગ હોય. એક અનુભવ અસ્થિર, ધીમો અને વિચિત્ર રીતે ભૂલી જનાર લાગે છે. બીજો અનુભવ ઝડપી, સુસંગત અને વિશ્વસનીય લાગે છે.
તફાવત ક્યારેય મોડલ પોતે નથી હોતો. તે તેની આસપાસ બનાવેલી સિસ્ટમ છે. એક ટીમે મોડલને આખું પ્રોડક્ટ માન્યું. બીજી ટીમે તેને એક શિસ્તબદ્ધ આર્કિટેક્ચરમાં એક ઘટક તરીકે જોયું. આ શિસ્ત એ 'હાર્નેસ' (harness) માં રહેલી છે.
પ્રોમ્પ્ટ્સથી આર્કિટેક્ચર તરફનું પરિવર્તન
શરૂઆતના AI ડેવલપમેન્ટમાં પ્રોમ્પ્ટ એન્જિનિયરિંગ પર મુખ્ય ધ્યાન આપવામાં આવતું હતું. શબ્દોમાં ફેરફાર કરવો, ઉદાહરણો ઉમેરવા અને રોલ-પ્લે સૂચનાઓ આપવાથી આઉટપુટની ગુણવત્તામાં મોટો સુધારો થઈ શકતો હતો. તે કૌશલ્ય હજુ પણ મહત્વનું છે, પરંતુ સ્પર્ધાત્મક લાભ (competitive moat) તરીકે તેના વળતર હવે ઘટતા જાય છે. તમે રિટ્રાય પોલિસી (retry policy) ના અભાવ અથવા ડેટા પાઇપલાઇનની સમસ્યાઓને પ્રોમ્પ્ટ દ્વારા સુધારી શકતા નથી, જે ખાનગી માહિતીને પબ્લિક રિસ્પોન્સમાં લીક કરી શકે છે.
અત્યારે જે સાચું પરિવર્તન થઈ રહ્યું છે તે સોફ્ટવેર આર્કિટેક્ચર તરફનું છે. એન્જિનિયરો સ્ટેટ મશીન્સ (state machines) ડિઝાઇન કરી રહ્યા છે, મોડલ લેયર અને એપ્લિકેશન લોજિક વચ્ચે કડક ઇન્ટરફેસ વ્યાખ્યાયિત કરી રહ્યા છે, અને નોન-ડિટરમિનિઝમ (non-determinism) ને એન્જિનિયરિંગની પ્રાથમિક ચિંતા તરીકે ગણી રહ્યા છે. તેઓ ડિસ્ટ્રિબ્યુટેડ સિસ્ટમ્સના પ્રશ્નો પૂછી રહ્યા છે: મલ્ટી-ટર્ન વાતચીત દરમિયાન સ્ટેટ કેવી રીતે જળવાઈ રહે છે? જ્યારે કોઈ ડાઉનસ્ટ્રીમ ટૂલ ઉપલબ્ધ ન હોય ત્યારે શું થાય? આપણે એવી સિસ્ટમનું પરીક્ષણ કેવી રીતે કરી શકીએ જેનું મુખ્ય ઘટક સંભવિતતા (probabilistic) પર આધારિત છે? આ એવા પ્રશ્નો છે જે એક રમકડાને સાચા સાધનથી અલગ કરે છે.
પ્રોડક્શન માટે નિર્માણ: ઓબ્ઝર્વેબિલિટી અને કંટ્રોલ
જો તમે પ્રોડક્ટ લોન્ચ કરવા માટે ગંભીર હોવ, તો હાર્નેસમાં બે ગુણો સૌથી મહત્વના છે: ઓબ્ઝર્વેબિલિટી (observability) અને ઓર્કેસ્ટ્રેશન (orchestration).
ઓબ્ઝર્વેબિલિટી એટલે કે તમે જોઈ શકો કે મોડલે શું મેળવ્યું, તેણે શું આપ્યું અને દરેક સ્ટેપમાં કેટલો સમય લાગ્યો. તેનો અર્થ એ છે કે ચૌદ ટૂલ કોલ્સ દરમિયાન એજન્ટના નિર્ણય લૂપને ટ્રેસ કરવો અને તે ક્યાંથી લૂપ થવા લાગ્યું અથવા તેના લક્ષ્યથી ભટકવા લાગ્યું તે ચોક્કસપણે ઓળખવું. તે વિઝિબિલિટી વગર, AI સિસ્ટમનું ડીબગિંગ કરવું એ અંધારામાં કારનું એન્જિન રિપેર કરવા જેવું છે.
ઓર્કેસ્ટ્રેશન એટલે કે તમારું બિઝનેસ લોજિક તમારા મોડલ ઇન્ટરેક્શન લેયરથી અલગ રહેવું જોઈએ. તેનો અર્થ એ છે કે પ્રોમ્પ્ટ્સનું વર્ઝનિંગ એવી રીતે કરવું જેમ તમે કોડનું વર્ઝનિંગ કરો છો, જેથી નવું ડિપ્લોયમેન્ટ અજાણતામાં વર્તનમાં ફેરફાર ન કરે. તેનો અર્થ એ છે કે નિષ્ફળતાના મોડ્સનું જાણીજોઈને પરીક્ષણ કરવું—જેમ કે રિક્વેસ્ટની વચ્ચે API બંધ કરી દેવી, ખોટા ટૂલ રિઝલ્ટ આપવા, કોન્ટેક્સ્ટ વિન્ડો ઓવરફ્લોનું અનુકરણ કરવું—તે જોવા માટે કે હાર્નેસ સિસ્ટમને સ્થિર રાખે છે કે નહીં. ફ્રેમવર્ક આવતા-જતા રહે છે, અને તમે તૈયાર ઓર્કેસ્ટ્રેશન લાઇબ્રેરી અપનાવો કે તમારી પોતાની બનાવો, બ્રાન્ડ નામ કરતાં શિસ્ત વધુ મહત્વની છે.
સાચો નિષ્કર્ષ
ફાઉન્ડેશન મોડલ્સ સતત સુધરતા રહેશે. તેઓ વધુ ઝડપી, સસ્તા અને વધુ સક્ષમ બનશે. પરંતુ વધુ શક્તિશાળી એન્જિન તૂટેલા ચેસીસને ઠીક કરી શકતું નથી. આગામી થોડા વર્ષોમાં જે ટીમો જીતશે તે સૌથી શ્રેષ્ઠ મોડલ એક્સેસ ધરાવતી ટીમો નહીં હોય. તે એવી ટીમો હશે જેમણે એવું હાર્નેસ બનાવ્યું હશે જે વિશ્વસનીય, ઓબ્ઝર્વેબલ અને સારી રીતે ઓર્કેસ્ટ્રેટેડ હોય. તેઓ તેમની એપ્લિકેશન્સ ફરીથી લખ્યા વગર મોડલ્સ બદલી શકશે. તેઓ ખર્ચ પર નિયંત્રણ રાખી શકશે કારણ કે હાર્નેસ દરેક ટોકનને નિયંત્રિત કરે છે. તેઓ શાંતિથી ઊંઘી શકશે કારણ કે તેમની સિસ્ટમ્સ નિષ્ફળતાને સારી રીતે સંભાળી લેશે.
માત્ર મોડલ પર જ ધ્યાન કેન્દ્રિત કરવાનું બંધ કરો. તેને ચલાવતી સિસ્ટમ પર ધ્યાન આપવાનું શરૂ કરો. ભવિષ્ય એ એન્જિનિયરોનું છે જેઓ સ્માર્ટ મોડલ્સની આસપાસ સ્માર્ટ સિસ્ટમ્સ બનાવે છે.
આ લેખ મૂળરૂપે Abdulaziz Zos દ્વારા "Beyond The Model" માં ચર્ચાયેલા વિચારો પર આધારિત છે.
AI એન્જિનિયરિંગ અને સિસ્ટમ ડિઝાઇન પર વધુ ચર્ચાઓ માટે, GyaanSetu learning community ની મુલાકાત લો.