નફો:
- ચાર સ્તંભો (સીડ ફિક્સેશન, ડેટા વર્ઝનિંગ, મીડિયા ફ્રીઝિંગ, પ્રયોગ મોનિટરિંગ) સાથે પુનઃઉત્પાદનક્ષમતા સુનિશ્ચિત કરવાની ક્ષમતા અને તે જ રનનું પુનરાવર્તન કરતી વખતે સમાન પરિણામ ઉત્પન્ન કરવાની ક્ષમતા
- મોડ્યુલના તમામ સ્ટોપ્સ (મેટ્રિક્સ, ડેટા, મોડલ, એલએલએમ ઘટકો, ઇવલ, ઔચિત્ય, સુરક્ષા, વિતરણ, મોનિટરિંગ) ને એન્ડ-ટુ-એન્ડ સાંકળમાં જોડવાની ક્ષમતા
- દરેક સ્ટોપ પર નિર્ણાયક નિર્ણય માનવ પાસે રહે છે તે ચકાસવાની ક્ષમતા અને ઓડિટેબલ રીતે પ્રોજેક્ટનું દસ્તાવેજીકરણ
ML પ્રોજેક્ટની સૌથી કપટી નિષ્ફળતા એ ક્રેશ નથી; "ફરીથી સમાન પરિણામ નથી મળતું." જો તમે ત્રણ મહિના પહેલા ઉત્પાદનમાં મૂકેલા મોડલના સ્કોર આજે પુનઃઉત્પાદિત કરી શકતા નથી, તો તમે ખરેખર તે મોડેલને નિયંત્રિત કરી શકતા નથી. આ બંધ એકમમાં, અમે પુનઃઉત્પાદનક્ષમતાને વધુ ઊંડું કરીએ છીએ: સમાન ઇનપુટ્સ સાથે સમાન પરિણામને વિશ્વસનીય રીતે મેળવવાની અને એન્ડ-ટુ-એન્ડ પ્રોજેક્ટ શિસ્તમાં સમગ્ર મોડ્યુલને જોડવાની ક્ષમતા.
શા માટે પ્રજનનક્ષમતા મુશ્કેલ છે
સામાન્ય સોફ્ટવેરમાં, સમાન કોડ સમાન આઉટપુટ આપે છે. ML માં ઘણા વધુ ચલો છે જે પરિણામ નક્કી કરે છે:
- રેન્ડમનેસ: ડેટા શફલિંગ, વેઇટ ઇનિશિયલાઇઝેશન, ડેટા સ્પ્લિટિંગ - બધું રેન્ડમનેસ પર આધાર રાખે છે.
- ડેટા: સમાન કોડ વિવિધ ડેટા સંસ્કરણ સાથે અલગ મોડેલ બનાવે છે.
- પર્યાવરણ: લાઇબ્રેરી વર્ઝન, હાર્ડવેર (CPU/GPU), ઓપરેટિંગ સિસ્ટમ પણ પરિણામ બદલી શકે છે.
- છુપાયેલ કેસ: એક વણસાચવેલ હાયપરપેરામીટર, એક મેન્યુઅલ પ્રીપ્રોસેસિંગ પગલું, એક અનોખી પસંદગી.
પ્રજનનક્ષમતા એ "સુંદર હોવું" નથી પરંતુ વૈજ્ઞાનિક અને ઇજનેરી આવશ્યકતા છે. પરિણામ જે પુનઃઉત્પાદિત કરી શકાતું નથી તે દાવો છે જે સાબિત કરી શકાતો નથી.
પ્રજનનક્ષમતાના ચાર સ્તંભો
1. રેન્ડમનેસને ઠીક કરો. બધા રેન્ડમ સીડ્સ એક જગ્યાએ સેટ કરો: ડેટા સ્પ્લિટિંગ, મોડલ આરંભ, ડેટા શફલિંગ. સ્થિર બીજ એ "જ્યારે તમે સમાન રનનું પુનરાવર્તન કરો છો ત્યારે સમાન પરિણામ" ગેરંટીનો આધાર છે.
2. ડેટાનું સંસ્કરણ. રેકોર્ડ કરો કે દરેક પ્રયોગ કયા ડેટા સંસ્કરણ સાથે કરવામાં આવ્યો હતો (એકમ 2 માં ડેટા સંસ્કરણ). "નવીનતમ ડેટા" અસ્પષ્ટ છે; "ડેટા સંસ્કરણ v3, hash abc123" ચોક્કસ છે.
3. માધ્યમને સ્થિર કરો. તમામ અવલંબનને તેમના ચોક્કસ વર્ઝન પર પિન કરો (દા.ત. numpy==1.26.4 in requirements.txt અથવા કન્ટેનર ઈમેજ જેવા ચોક્કસ વર્ઝન). "નવીનતમ સંસ્કરણ" એક દિવસ બધું તોડી નાખશે.
4. બધું ટ્રૅક કરો (પ્રયોગ ટ્રેકિંગ). દરેક પ્રયોગ માટે આપમેળે સાચવો: કોડ વર્ઝન (ગિટ કમિટ), ડેટા વર્ઝન, બધા હાયપરપેરામીટર્સ, મેટ્રિક્સ અને આઉટપુટ સ્ટ્રક્ચર્સ. MLflow, Weights & Biases જેવા પ્રયોગ ટ્રેકિંગ સાધનો આ વ્યવસ્થિત રીતે કરે છે. નોંધણી વિના, "કયું સેટિંગ શ્રેષ્ઠ હતું" પ્રશ્ન અનુત્તરિત રહે છે.
સાવધાન: "હું પછીથી યાદ કરીશ" એ સૌથી મોંઘી ભ્રમણા છે. બે અઠવાડિયા પછી તમને યાદ રહેશે નહીં કે તમે કયું બીજ, કયો ડેટા, કયો હાઇપરપેરામીટરનો ઉપયોગ કર્યો છે. સ્વચાલિત ટ્રેકિંગ મેમરી પરની નિર્ભરતાને દૂર કરે છે.
નબળા અભિગમ / મજબૂત અભિગમ
નબળા: "મને શ્રેષ્ઠ મોડેલ મળ્યું, તે નોટબુક પર છે, મને લાગે છે કે તેનો સ્કોર 89% હતો."
મજબૂત: "પ્રયોગ ટ્રેકિંગ ટૂલમાં #147 ચલાવો: git કમિટ a3f9c, ડેટા વર્ઝન v3 (hash abc123), સીડ 42, બધા હાઇપરપેરામીટર્સ રજીસ્ટર્ડ, ટેસ્ટ PR-AUC 0.887. જ્યારે હું તે જ આદેશને ફરીથી ચલાવું છું, ત્યારે મને તે જ પરિણામ મળે છે. મોડલ રજિસ્ટ્રીમાં આ રન પર આધારિત છે."
તફાવત: મજબૂત અભિગમમાં પરિણામ મેમરી પર આધારિત નથી, પરંતુ નિશ્ચિત અને મોનિટર કરેલ સાંકળ પર આધારિત છે. દરેક વ્યક્તિ દરેક વખતે સમાન પરિણામ લાવી શકે છે.
એન્ડ-ટુ-એન્ડ પ્રોજેક્ટ: મોડ્યુલનું સંયોજન
હવે આખા મોડ્યુલને એક પ્રોજેક્ટ ફ્લોમાં જોડીએ. વાસ્તવિક ML સિસ્ટમ આ સ્ટોપ્સમાંથી પસાર થાય છે, અને દરેક સ્ટોપ પાછલા એક પર બને છે:
- સમસ્યાની વ્યાખ્યા: આપણે શું હલ કરી રહ્યા છીએ, સફળતા કેવી રીતે માપવી (એકમ 3: યોગ્ય મેટ્રિક, વ્યવસાય સંદર્ભ). મેટ્રિક અને થ્રેશોલ્ડ શરૂઆતથી જ સ્પષ્ટ છે.
- ડેટા પાઇપલાઇન: સંગ્રહ, માન્યતા, સફાઇ, લીક-મુક્ત પાર્ટીશન, સંસ્કરણ (યુનિટ 2).
- મોડલ ડેવલપમેન્ટ: તાલીમ, આધારરેખા સરખામણી, ક્રોસ-વેલિડેશન, સખત બીજ (એકમ 3 + આ એકમ).
- LLM ઘટકો (જો લાગુ હોય તો): RAG (યુનિટ 4) અને/અથવા એજન્ટો (એકમ 5); જો જરૂરી હોય તો ફાઇન-ટ્યુનિંગ (એકમ 6).
- મૂલ્યાંકન: એજ અને સિક્યોરિટી કેસ સાથે ઇવલ ક્લસ્ટર, એલએલએમ સિસ્ટમ્સમાં મલ્ટિ-લેયર ઇવેલ (એકમ 8).
- ન્યાય અને નીતિશાસ્ત્ર ઓડિટ: પેટાજૂથ વિશ્લેષણ, મોડેલ કાર્ડ, સમજાવવાની ક્ષમતા (એકમ 10).
- સુરક્ષા ઓડિટ: પ્રોમ્પ્ટ ઈન્જેક્શન, પ્રાઈવસી, સપ્લાય ચેઈન (યુનિટ 9).
- વિતરણ: પેકેજિંગ, ક્રમિક વિતરણ, રોલબેક, મોડેલ રજિસ્ટ્રી (યુનિટ 7).
- મોનિટરિંગ: થ્રી-લેયર મોનિટરિંગ, ડ્રિફ્ટ એલાર્મ (યુનિટ 8).
- પુનઃઉત્પાદનક્ષમતા: સમગ્ર સાંકળમાં (આ એકમ) બીજ, ડેટા સંસ્કરણ, મીડિયા અને પ્રયોગ ટ્રેકિંગ.
આ પ્રવાહમાં, AI એ દરેક સ્ટોપ પર પ્રવેગક અને બ્લુપ્રિન્ટ જનરેટર છે; પરંતુ મેટ્રિક પસંદગી, ડેટા નિર્ણયો, ઔચિત્યની પ્રાધાન્યતા, જમાવટ થ્રેશોલ્ડ અને રિલીઝ મંજૂરી — નિર્ણાયક નિર્ણયો માનવ પાસે રહે છે. આ મોડ્યુલનો સાર છે.
દસ્તાવેજીકરણ: ભવિષ્ય તમારો આભાર માનશે
એક સારો ML પ્રોજેક્ટ પોતે જ દસ્તાવેજ કરે છે. ઓછામાં ઓછું, નીચે લખવું જોઈએ: સમસ્યા અને સફળતાના માપદંડ, ડેટા સ્ત્રોત અને સંસ્કરણ, મોડેલની પસંદગી અને સમર્થન, મૂલ્યાંકન પરિણામો (પેટાજૂથો સહિત), જાણીતી મર્યાદાઓ અને જોખમો, જમાવટ અને પુનઃપ્રાપ્તિ પ્રક્રિયા, મોનિટરિંગ પ્લાન. આ દસ્તાવેજ એ વ્યક્તિનો શ્રેષ્ઠ મિત્ર છે (કદાચ તે તમે છો) જે છ મહિના પછી પ્રોજેક્ટ પર પાછા ફરે છે.
ત્રણ નાના કેસો
કેસ 1 - પરિણામ ગુમાવ્યું. એક એન્જિનિયરે એક મહાન મોડેલને તાલીમ આપી, પરંતુ તેણે બીજને ઠીક કર્યું નહીં અને ડેટા સંસ્કરણને સાચવ્યું નહીં. જ્યારે તેણે નોકરી છોડી દીધી, ત્યારે કોઈ પણ તે પરિણામનું પુનરુત્પાદન કરી શક્યું નહીં; મોડલ "બ્લેક બોક્સ લિજેન્ડ" બની ગયું અને આખરે શરૂઆતથી જ બનાવવામાં આવ્યું. અઠવાડિયા બરબાદ થયા. પાઠ: પુનઃઉત્પાદન ન કરી શકાય તેવું પરિણામ એ અસ્તિત્વમાં નથી.
કેસ 2 - પર્યાવરણનું પતન. એક ટીમે નિર્ભરતા નિશ્ચિત કરી ન હતી. જ્યારે લાઇબ્રેરી આપમેળે અપડેટ થાય છે, ત્યારે મોડલ આઉટપુટ શાંતિપૂર્વક બદલાઈ જાય છે અને ઉત્પાદન ખોરવાઈ ગયું હતું. સમસ્યા શોધવામાં દિવસો લાગ્યા. જ્યારે નિર્ભરતા સ્થિર કરવામાં આવી હતી અને નિશ્ચિત સંસ્કરણો સાથે કન્ટેનરાઇઝ્ડ કરવામાં આવી હતી, ત્યારે સમસ્યા ફરીથી આવી ન હતી. પાઠ: પર્યાવરણને સ્થિર કરો.
કેસ 3 - દેખરેખની શક્તિ. એક ટીમે દરેક પ્રયોગનું આપમેળે નિરીક્ષણ કર્યું. ત્રણ મહિના પછી, એક નિયમનકારી ઓડિટ દરમિયાન, તેઓએ "કયા ડેટા સાથે, કયા સેટિંગ્સ સાથે, કયા જૂથોમાં તે શું પ્રદર્શન મેળવ્યું?" પ્રશ્નનો જવાબ આપ્યો. મિનિટોમાં સંપૂર્ણ રેકોર્ડિંગ સાથે. નિરીક્ષણ સરળ રીતે થયું. પાઠ: મોનીટરીંગ એ એક અનુપાલન સાધન છે, માત્ર એન્જીનિયરીંગ નથી.
નકલ કરી શકાય તેવા નમૂનાઓ
આ ML પ્રોજેક્ટ માટે પુનઃઉત્પાદનક્ષમતા તપાસો.- શું બધા અવ્યવસ્થિતતા બીજ નિશ્ચિત છે (વિભાજન, પ્રારંભ, શફલ)?- શું ડેટા સંસ્કરણ છે?- શું નિર્ભરતા ચોક્કસ સંસ્કરણો પર સ્થિર છે?- શું દરેક પ્રયોગ (કોડ કમિટ, ડેટા, હાઇપરપેરામીટર, મેટ્રિક) ટ્રેક કરવામાં આવે છે? દરેક ખૂટતી કૉલમ માટે તેને કેવી રીતે ઠીક કરવું તેના પર નક્કર પગલાં લખો. પ્રોજેક્ટ માળખું: [વર્ણન]
આ એન્ડ-ટુ-એન્ડ એમએલ પ્રોજેક્ટ માટે પ્લાન સ્કેલેટન બનાવો. સમસ્યા: [વર્ણન] નીચેના સ્ટોપ્સને આવરી લો અને દરેક સ્ટોપ પર માનવ નિર્ણય ક્યાં છે તે ચિહ્નિત કરો: સમસ્યા/મેટ્રિક, પાઇપલાઇન, મોડેલ, (RAG/એજન્ટ/ફાઇન-ટ્યુન?), ઇવલ, ઔચિત્ય, સુરક્ષા, વિતરણ, દેખરેખ, પ્રજનનક્ષમતા. દરેક સ્ટોપ માટે મુખ્ય જોખમ અને ચકાસણીનું પગલું લખો.
આ પ્રોજેક્ટ માટે તકનીકી દસ્તાવેજીકરણ ટેમ્પલેટ બનાવો. વિભાગો: સમસ્યા+સફળતાના માપદંડ, ડેટા (સ્રોત+સંસ્કરણ), મોડેલ પસંદગીઓ+વાજબીતા, મૂલ્યાંકન (પેટાજૂથો સહિત), જાણીતી મર્યાદા+જોખમો, જમાવટ+રોલબેક, મોનિટરિંગ પ્લાન. પ્રશ્નો તરીકે દરેક વિભાગ માટે ભરવાના ક્ષેત્રો આપો.
મારું પ્રયોગ મોનિટરિંગ સેટઅપ તપાસો: શું તે દરેક રન પર સ્વતઃ-સેવ થાય છે: ગિટ કમિટ, ડેટા સંસ્કરણ/હેશ, બધા હાઇપરપેરામીટર્સ, તમામ મેટ્રિક્સ, પર્યાવરણ (લાઇબ્રેરી સંસ્કરણો)? જ્યારે હું તે જ દોડ ફરીથી ચલાવું ત્યારે શું મને સમાન પરિણામ મળે છે? સેટઅપ: [વર્ણન]. ખામીઓ અને સુધારણાની સૂચિ બનાવો.
પ્રજનનક્ષમતા કૉલમ ટેબલ
કૉલમ
શું નિશ્ચિત છે
વાહનનું ઉદાહરણ
અવ્યવસ્થિતતા
બધા બીજ
બીજ સેટિંગ
ડેટા
ડેટા વર્ઝન/હેશ
ડીવીસી
પર્યાવરણ
પુસ્તકાલય આવૃત્તિઓ
જરૂરિયાતો પિન, ડોકર
મોનીટરીંગ
કોડ+ડેટા+સેટિંગ+મેટ્રિક
MLflow, W&B
સામાન્ય ભૂલો
- બીજ ફિક્સિંગ નથી. પરિણામનું પુનરાવર્તન કરી શકાતું નથી.
- ડેટા સંસ્કરણ સાચવી રહ્યું નથી. "કયા ડેટા સાથે?" અનુત્તરિત રહે છે.
- વ્યસનો થીજી ન જાય. અપડેટ ચુપચાપ બધું તોડી નાખશે.
- પ્રયોગોને મેમરી પર છોડીને. બે અઠવાડિયા પછી કંઈ યાદ નથી.
- જટિલ નિર્ણયો આર્ટિફિશિયલ ઇન્ટેલિજન્સ પર છોડી દેવા. મેટ્રિક્સ, ન્યાય અને વિતરણના નિર્ણયો લોકો પાસે રહેવા જોઈએ.
- દસ્તાવેજીકરણ મુલતવી રાખવું. ભાવિ ટીમ (અને તમે) કિંમત ચૂકવે છે.
સારાંશમાં
પુનઃઉત્પાદનક્ષમતા એ ગંભીર ML એન્જિનિયરિંગની સહી છે: બિન-પ્રજનનક્ષમ પરિણામ એ અપ્રુવેબલ દાવો છે. તે ચાર કૉલમ સાથે આવે છે — ફિક્સ રેન્ડમનેસ, વર્ઝન ડેટા, ફ્રીઝ એન્વાયર્નમેન્ટ, દરેક પ્રયોગને ટ્રૅક કરો. એન્ડ-ટુ-એન્ડ પ્રોજેક્ટ આ મોડ્યુલના તમામ સ્ટોપ્સ (મેટ્રિક, ડેટા, મોડલ, એલએલએમ ઘટકો, ઇવલ, ફેરનેસ, સુરક્ષા, વિતરણ, મોનિટરિંગ) ને એકબીજા સાથે જોડાયેલ સાંકળમાં જોડે છે; કૃત્રિમ બુદ્ધિ એ દરેક સ્ટોપ પર પ્રવેગક છે, પરંતુ નિર્ણાયક નિર્ણયો માનવ સાથે રહે છે. ભવિષ્યની ટીમ અને ઑડિટ માટે બધું દસ્તાવેજ કરો. આ શિસ્ત એ ફ્રેમવર્ક છે જે તમે સમગ્ર મોડ્યુલમાં શીખો છો તે બધું ટકાવી રાખે છે.
એપ્લિકેશન કાર્ય
ચાર પુનઃઉત્પાદનક્ષમતા સ્તંભો સામે ML પ્રોજેક્ટ તપાસો: શું બીજ અપરિવર્તનશીલ છે, શું ડેટા વર્ઝન થયેલ છે, શું પર્યાવરણ સ્થિર છે, શું પ્રયોગો ટ્રેક કરવામાં આવ્યા છે? કોઈપણ ખૂટતી કૉલમને ઠીક કરો અને સાબિત કરો કે તમે એક જ રનને બે વાર ચલાવી શકો છો અને સમાન પરિણામ મેળવી શકો છો. પછી એક પેજ પર પ્રોજેક્ટના એન્ડ-ટુ-એન્ડ ફ્લો (10 સ્ટોપ્સ) આઉટપુટ કરો અને દરેક સ્ટોપ પર "જ્યાં માનવ નિર્ણય છે" ચિહ્નિત કરો. છેલ્લે, એક ટૂંકી તકનીકી દસ્તાવેજીકરણ ડ્રાફ્ટ લખો.
ચેકલિસ્ટ
- [ ] બધા અવ્યવસ્થિત બીજ નિશ્ચિત.
- દરેક પ્રયોગ સાથે ડેટા વર્ઝન/હેશ રેકોર્ડ કરવામાં આવે છે.
- [ ] નિર્ભરતાઓ ફર્મ વર્ઝન (પિન/કન્ટેનર) પર સ્થિર થાય છે.
- [ ] દરેક પ્રયોગનું આપમેળે નિરીક્ષણ કરવામાં આવે છે (કોડ+ડેટા+સેટિંગ+મેટ્રિક).
- [ ] જ્યારે હું તે જ દોડનું પુનરાવર્તન કરું છું, ત્યારે મને તે જ પરિણામ મળે છે.
- [ ] મેં ચકાસ્યું અને દસ્તાવેજીકૃત કર્યું કે અંત-થી-અંતના પ્રવાહમાં નિર્ણાયક નિર્ણયો મનુષ્યો દ્વારા લેવામાં આવે છે.
મોડ્યુલ પરીક્ષા
1. એક ML એન્જિનિયર તરીકે, વર્કફ્લોમાં કૃત્રિમ બુદ્ધિમત્તાને સ્થાન આપતી વખતે શ્રેષ્ઠ અભિગમ કયો છે?
- A) AI એ ઓછા જોખમવાળા વ્યવસાયોમાં પ્રવેગક છે; મેટ્રિક્સ, ડેટા અને ઉત્પાદન જેવા નિર્ણાયક નિર્ણયો માન્ય રહે છે અને માનવ પર છોડી દેવામાં આવે છે ✔
- B) જ્યાં સુધી AI આઉટપુટ સારા દેખાય ત્યાં સુધી ચકાસણીની જરૂર નથી
- C) મોડેલને ઉત્પાદનમાં કૃત્રિમ બુદ્ધિમત્તા પર મૂકવાના નિર્ણયને છોડી દેવાથી સમય બચે છે.
- ડી) આર્ટિફિશિયલ ઈન્ટેલિજન્સ માત્ર ટેક્સ્ટ લખવા માટે જ ઉપયોગી છે, તેને ડેટા અને મોડલ વર્ક સાથે કોઈ લેવાદેવા નથી
વર્ણન: AI એ ઓછા જોખમવાળા, સરળતાથી ચકાસાયેલ કાર્યો જેમ કે કોડ, ડેટા ડાયજેસ્ટ અને દસ્તાવેજો માટે એક શક્તિશાળી પ્રવેગક છે; જો કે, પૈસા, ગોપનીયતા અને કાનૂની જવાબદારીને અસર કરતા નિર્ણયોની જવાબદારી, જેમ કે મેટ્રિક પસંદગી, જે ડેટા તાલીમમાં જાય છે અને મોડેલને ઉત્પાદનમાં મૂકે છે, તે યોગ્ય ઇજનેર અને ટીમની છે. ચકાસણી વિના દરેક આઉટપુટનો ઉપયોગ થવો જોઈએ નહીં.
2. ડેટા પાઇપલાઇનની શરૂઆતમાં સ્કીમા માન્યતા શા માટે મૂકવામાં આવે છે?
- A) કારણ કે તે સીધા જ મોડેલની ચોકસાઈ વધારે છે
- બી) કારણ કે તે ડેટા વર્ઝનિંગને બિનજરૂરી બનાવે છે
- C) કારણ કે તે દૂષિત ડેટાને વહેલામાં વહેલી તકે અને સૌથી સસ્તો પોઈન્ટ પકડી લે છે અને તેને આગળના પગલાઓમાં લીક થતા અટકાવે છે ✔
- ડી) કારણ કે તે લેબલીંગની જરૂરિયાતને દૂર કરે છે
સમજૂતી: અગાઉનો ભ્રષ્ટ ડેટા પકડાય છે, તેને ઠીક કરવો તેટલો સસ્તો છે. સ્કીમા માન્યતા લાઇનની શરૂઆતમાં અપેક્ષિત પ્રકાર અને શ્રેણીની બહારના ડેટાને નકારીને પ્રશિક્ષણ અથવા ઉત્પાદનમાં ચુપચાપ લીક થતા ભ્રષ્ટ ડેટાને અટકાવે છે (દા.ત. એકમ ફેરફાર સાથે કિંમત 100x શિફ્ટિંગ); ઉત્પાદનમાં પકડાયેલી સમાન ભૂલ ઘણી ગણી વધુ ખર્ચાળ છે.
3. સમય (સમય શ્રેણી) સાથે સંકળાયેલી સમસ્યામાં ડેટાને તાલીમ અને પરીક્ષણમાં વિભાજીત કરતી વખતે સાચો અભિગમ શું છે?
- A) રેન્ડમ સ્પ્લિટિંગનો ઉપયોગ કરવો કારણ કે તે હંમેશા સૌથી યોગ્ય પદ્ધતિ છે
- બી) ટેમ્પોરલ સ્પ્લિટિંગનો ઉપયોગ કરીને: ભૂતકાળની તાલીમ અને ભવિષ્યમાં પરીક્ષણ કરીને લિકેજને અટકાવો ✔
- C) તાલીમ અને પરીક્ષણ બંને તરીકે તમામ ડેટાનો ઉપયોગ કરવો
- ડી) પ્રશિક્ષણ પહેલાં સ્કેલિંગ પરિમાણોમાં પરીક્ષણ ડેટાનો સમાવેશ કરવો
સમજૂતી: સમયની શ્રેણી પર રેન્ડમ વિભાજન મોડલને 'ભવિષ્ય-જોવા'નો ફાયદો આપે છે જે ઉત્પાદનમાં ક્યારેય થશે નહીં અને કૃત્રિમ રીતે મેટ્રિક્સ (ટેમ્પોરલ લિકેજ) વધે છે. સાચો એક ટેમ્પોરલ ડિવિઝન છે: ભૂતકાળ સાથે ટ્રેન, ભવિષ્યમાં પરીક્ષણ. આ વાસ્તવિક કામગીરીને માપે છે જે તેને ઉત્પાદનમાં રાખે છે.
4. 1.5% ના હકારાત્મક વર્ગ દર સાથે છેતરપિંડી શોધ મોડેલમાં શા માટે ચોકસાઈ ભ્રામક છે?
- A) કારણ કે અસંતુલિત ડેટા પર ચોકસાઈ હંમેશા ઓછી હોય છે
- B) કારણ કે ચોકસાઈનો ઉપયોગ ફક્ત રીગ્રેસન સમસ્યાઓ પર જ થઈ શકે છે
- C) કારણ કે ચોકસાઈની ગણતરી માટે ઘણી બધી પ્રક્રિયા શક્તિની જરૂર પડે છે
- ડી) બહુમતી વર્ગની આગાહી કરતું નજીવું મોડેલ પણ ખૂબ જ સચોટ હોઈ શકે છે, આમ વાસ્તવિક સફળતા છુપાવે છે ✔
સમજૂતી: અસંતુલિત ડેટા પર, 'કોલ એવરીથિંગ નેગેટિવ' કહેતું મૂળભૂત મોડલ પણ લગભગ 98.5% ચોકસાઈ મેળવે છે પરંતુ એક પણ છેતરપિંડી પકડશે નહીં. તેથી, અસંતુલિત વર્ગીકરણમાં, ચોકસાઈને બદલે ચોકસાઇ, રિકોલ, F1 અથવા PR-AUC નો ઉપયોગ કરવામાં આવે છે, અને દરેક મેટ્રિકને બેઝ મોડેલ અનુસાર અર્થઘટન કરવામાં આવે છે.
5. મોડેલના મેટ્રિક વિશે વાત કરતી વખતે બેઝલાઇન સરખામણી શા માટે જરૂરી છે?
- A) કારણ કે બેઝ મોડલ હંમેશા વાસ્તવિક મોડલ કરતા વધુ સારું હોય છે
- B) કારણ કે તે સ્પષ્ટ છે કે મેટ્રિક અર્થપૂર્ણ છે કે નહીં માત્ર ત્યારે જ જ્યારે સરળ બેઝલાઇન મોડલની સરખામણી કરવામાં આવે ✔
- C) કારણ કે બેઝ મોડેલ ક્રોસ-વેલિડેશનને બિનજરૂરી બનાવે છે
- ડી) કારણ કે દરેક રિપોર્ટમાં મૂળભૂત મોડલ કાયદેસર રીતે જરૂરી છે
સમજૂતી: મેટ્રિક પોતે સારું કે ખરાબ નથી હોતું; મૂળભૂત મોડેલ મુજબ તે સારું કે ખરાબ છે. '85% સાચો' વાક્યનો અર્થ લગભગ નકામો છે જો બેઝ મોડેલ પહેલેથી જ 84% મેળવે છે, અને જો તે 50% મેળવે તો સંપૂર્ણ. સરખામણી એન્કર વિના, મેટ્રિક અર્થહીન છે.
6. સૌથી મહત્વપૂર્ણ સુરક્ષા તત્વ કયું છે જેનો આરએજી (પુનઃપ્રાપ્તિ-સંવર્ધિત જનરેશન) સિસ્ટમના ઉત્પાદન પ્રોમ્પ્ટમાં સમાવેશ થવો જોઈએ?
- A) આપેલ સ્ત્રોત પર જ આધાર રાખવાની સૂચના, સ્ત્રોત અસ્તિત્વમાં ન હોય તો 'મને ખબર નથી' એમ કહેવું અને સ્ત્રોત ટાંકવા માટે ✔
- બી) મોડેલને શક્ય તેટલા લાંબા અને સર્જનાત્મક જવાબો આપવાનું કહેવું
- C) મોડેલ તેના પોતાના શૈક્ષણિક જ્ઞાનને સંસાધનો પર પ્રાથમિકતા આપે છે
- ડી) આદેશો તરીકે લાવવામાં આવેલા દસ્તાવેજોમાંની તમામ સૂચનાઓનો અમલ કરો
સમજૂતી: RAG ની એકમાત્ર સૌથી મહત્વપૂર્ણ સૂચના એ છે કે મોડેલને ફક્ત આપેલા સ્ત્રોત પર આધાર રાખવાનું કહેવું, અને જો માહિતી સ્ત્રોતમાં ન હોય, તો 'મને ખબર નથી' કહો અને તેને બનાવ્યા વિના સ્રોત ટાંકો. આ ટ્રાયડ વિના, મોડેલ સંદર્ભને અવગણી શકે છે અને આભાસ પેદા કરી શકે છે, અને જવાબ અચકાસાયેલ બની જાય છે.
7. એક RAG સિસ્ટમ ખોટા જવાબો આપે છે. નિદાન શરૂ કરવા માટે શ્રેષ્ઠ સ્થાન ક્યાં છે?
- A) પ્રથમ લાવવાનું માપવું (રિકોલ@K): શું સાચો ભાગ ક્યારેય આવે છે? ✔
- બી) તરત જ મોડેલને મોટા સાથે બદલો
- સી) અવ્યવસ્થિત રીતે પ્રોમ્પ્ટ બદલો અને પ્રયાસ કરવાનું ચાલુ રાખો
- ડી) ફાઇન-ટ્યુનિંગ સાથે મોડેલમાં તમામ દસ્તાવેજોને એમ્બેડ કરવું
સમજૂતી: RAG ની સૌથી નબળી કડી સામાન્ય રીતે મેળવે છે, ઉત્પાદન નહીં. જો સાચો ભાગ ક્યારેય લાવવામાં ન આવે, તો મોડલ તે માહિતી ઉત્પન્ન કરી શકશે નહીં, પછી ભલે ગમે તેટલો પ્રોમ્પ્ટ સુધારવામાં આવે. તેથી, સાચો ભાગ આવ્યો છે કે કેમ તે જોવા માટે પ્રથમ Recall@K માપવામાં આવે છે; જો આનયન સારું છે, તો ઉત્પાદન અને પ્રોમ્પ્ટની તપાસ કરવામાં આવે છે.
8. એજન્ટને સાધન આપતી વખતે માનવીય મંજૂરી પાછળ કઈ ક્રિયાઓ રાખવી જોઈએ?
- એ) કોઈ નહીં; એજન્ટ દરેક ક્રિયા સ્વાયત્ત રીતે કરવા સક્ષમ હોવા જોઈએ
- B) માત્ર ઉલટાવી શકાય તેવી ક્રિયાઓ જેમ કે ડેટા વાંચવા અને શોધવા
- C) ઉલટાવી શકાય તેવી અથવા ઉચ્ચ અસરવાળી ક્રિયાઓ જેમ કે પૈસા ટ્રાન્સફર કરવા, ડિલીટ કરવા, મોકલવા ✔
- ડી) ક્રિયાઓ જેમાં માત્ર ગણતરીઓ સામેલ છે
વર્ણન: ક્રિયાઓ જોખમ સ્તર દ્વારા અલગ કરવામાં આવે છે. પુનઃપ્રાપ્ત કરી શકાય તેવા કાર્યો જેમ કે વાંચન, શોધ, ગણતરી અને ડ્રાફ્ટ જનરેટ કરવા સ્વાયત્ત રીતે કરી શકાય છે; જો કે, ઉલટાવી ન શકાય તેવી અથવા ઉચ્ચ-અસરકારક ક્રિયાઓ જેમ કે પૈસા ટ્રાન્સફર કરવા, ઈમેઈલ મોકલવા, ડેટા ડિલીટ કરવા, ઓર્ડર આપવા વગેરેને માનવીય મંજૂરીની જરૂર હોય છે. દરેક ઉલટાવી શકાય તેવી ક્રિયા સંમતિને આધીન હોવી જોઈએ.
9. પરોક્ષ પ્રોમ્પ્ટ ઇન્જેક્શનના જોખમ સામે શ્રેષ્ઠ ડિઝાઇન અભિગમ શું છે?
- A) સિસ્ટમ પ્રોમ્પ્ટમાં 'ખરાબ સૂચનાઓને અવગણો' એક વાક્ય ઉમેરવા માટે તે પૂરતું છે
- બી) બાહ્ય સામગ્રીની સૂચનાઓ પર આધાર રાખીને મોડેલને વધુ સત્તા આપો
- સી) કોઈ સાવચેતી ન લેવી કારણ કે ઈન્જેક્શન અટકાવી શકાય તેવું નથી
- ડી) બાહ્ય સામગ્રીને અવિશ્વસનીય ડેટા તરીકે અલગ કરવી અને ન્યૂનતમ અધિકૃતતા, મંજૂરી અને આઉટપુટ નિયંત્રણ સાથે સ્તરીય સંરક્ષણ સ્થાપિત કરવું ✔
વર્ણન: એજન્ટ અથવા આરએજી દ્વારા પ્રક્રિયા કરાયેલ બાહ્ય સામગ્રી, જેમ કે વેબ પેજ, દસ્તાવેજ, ઈમેલ વગેરે, અવિશ્વસનીય ડેટા છે અને તેમાં ગુપ્ત સૂચનાઓ હોઈ શકે છે. યોગ્ય અભિગમ સ્તરીય સંરક્ષણ છે: સ્પષ્ટ સીમાંકરો સાથે બાહ્ય સામગ્રીને 'ડેટા, આદેશો નહીં' તરીકે અલગ પાડવી, ન્યૂનતમ અધિકૃતતા લાગુ કરવી, માનવીય મંજૂરી માટે બદલી ન શકાય તેવી ક્રિયાઓનું બંધન કરવું અને આઉટપુટનું ઑડિટ કરવું. સૂચનાઓની એક લીટી પૂરતી નથી.
10. ફાઇન-ટ્યુનિંગ અથવા RAG વડે સમસ્યા ઉકેલવી જોઈએ કે કેમ તે નક્કી કરતી વખતે મુખ્ય તફાવત શું છે?
- A) માહિતીની સમસ્યાઓ આરએજી સાથે વધુ સારી રીતે ઉકેલવામાં આવે છે, વર્તણૂક/ફોર્મેટ સમસ્યાઓ ફાઇન-ટ્યુનિંગ સાથે વધુ સારી રીતે હલ થાય છે ✔
- બી) દરેક સમસ્યા હંમેશા ફાઈન ટ્યુનિંગ દ્વારા ઉકેલવી જોઈએ
- C) RAG નો ઉપયોગ માત્ર કોડ જનરેશન માટે થાય છે, ફાઈન-ટ્યુનિંગનો ઉપયોગ માત્ર અનુવાદ માટે થાય છે
- ડી) ફાઇન-ટ્યુનિંગ હંમેશા RAG કરતાં સસ્તી અને ઝડપી અપડેટ કરી શકાય છે
સમજૂતી: મોડલ નવી માહિતી શીખવવામાં ફાઇન-ટ્યુનિંગ નબળી અને જોખમી છે; પરંતુ શિક્ષણ વર્તન, ફોર્મેટ, સ્વર અને શૈલીમાં શક્તિશાળી છે. 'મોડલ કંપની અમારા ડેટાને જાણતી નથી' એ માહિતીની સમસ્યા છે અને તે RAGની છે. 'મૉડલને હંમેશા અમારા કડક ફોર્મેટમાં આઉટપુટ કરવા દો' એ વર્તણૂકીય સમસ્યા છે અને ફાઇન-ટ્યુનિંગ માટે ઉમેદવાર છે. વધુમાં, ફાઇન-ટ્યુનિંગ પહેલાં પ્રોમ્પ્ટ અને થોડા-શૉટ્સનું સેવન કરવું જોઈએ.
11. ઉત્પાદનમાં નવું મોડેલ મૂકતી વખતે સલામત જમાવટ માટે કયું ફરજિયાત છે?
- A) જો મોડેલ પરીક્ષણમાં સારું છે, તો તેને સીધા 100% ટ્રાફિક માટે ખોલો
- બી) જમાવટ પછી બિલકુલ મોનિટરિંગ સેટ ન કરવું
- સી) તબક્કાવાર જમાવટ (શેડો/કેનેરી) અને પૂર્વ-પરીક્ષણ રોલબેક યોજના ✔
- ડી) મૂલ્યાંકન થ્રેશોલ્ડ પૂર્ણ ન થાય તો પણ મોડેલ પ્રકાશિત કરવું
સમજૂતી: નવા મોડલને તમામ ટ્રાફિક માટે સીધું ખોલવું જોખમી છે; જો તે ખોટું છે, તો દરેકને અસર થાય છે. સાચી વાત એ છે કે તે ક્રમશઃ વિતરણ છે (શેડો, કેનેરી) અને દરેક વિતરણમાં ચકાસાયેલ રોલબેક પ્લાન છે. ક્લોબેક યોજના વિના વિતરણ પૂર્ણ થતું નથી; જ્યારે મોડલ ઉત્પાદનમાં અણધારી રીતે વર્તે છે ત્યારે મિનિટોની અંદર પાછલા સંસ્કરણ પર પાછા ફરવા સક્ષમ થવાથી વપરાશકર્તાનું રક્ષણ થાય છે.
12. ML મોડલ ઉત્પાદનમાં 'ચુપચાપ' કેવી રીતે નિષ્ફળ થઈ શકે છે અને આને પકડવાની રીત શું છે?
- એ) મોડેલ તૂટી જાય છે; સર્વર લોગ આ દર્શાવે છે
- બી) ભૂલો કર્યા વિના ખોટી આગાહીઓ ઉત્પન્ન કરીને; ✔ તે ઓપરેશનલ, ઇનપુટ અને આઉટપુટ સ્તરીય મોનિટરિંગને કેપ્ચર કરે છે
- C) મોડલ ક્યારેય ચુપચાપ નિષ્ફળ ન થઈ શકે, હંમેશા એલાર્મ
- ડી) કોઈપણ અધોગતિને પકડવા માટે માત્ર લેટન્સીનું નિરીક્ષણ કરવું પૂરતું છે
સમજૂતી: મોડેલ ક્રેશ થયા વિના અથવા ભૂલો આપ્યા વિના ખોટી આગાહીઓ ઉત્પન્ન કરીને નિષ્ફળ થઈ શકે છે; તેનું મુખ્ય કારણ ડેટા ડ્રિફ્ટ અને કોન્સેપ્ટ ડ્રિફ્ટ છે. માત્ર ઓપરેશનલ મેટ્રિક્સ (લેટન્સી, એરર રેટ)નું નિરીક્ષણ કરવું પૂરતું નથી; ઇનપુટ વિતરણ અને આઉટપુટ/અનુમાન વિતરણનું પણ નિરીક્ષણ કરવું જોઈએ. જો વાસ્તવિક પરિણામમાં વિલંબ થાય તો ઇનપુટ ડ્રિફ્ટ પ્રારંભિક ચેતવણી આપે છે.
13. LLM સિસ્ટમનું મૂલ્યાંકન કરવા માટે LLM-એ-જજનો ઉપયોગ કરતી વખતે કયો સિદ્ધાંત આવશ્યક છે?
- A) LLM-રેફરી હંમેશા સાચો છે, માનવીય ચકાસણી બિનજરૂરી છે
- બી) રેફરીએ માત્ર જવાબની લંબાઈના આધારે નિર્ણય લેવો જોઈએ.
- સી) જ્યારે રેફરીઓનો ઉપયોગ કરવામાં આવે ત્યારે નિયમો-આધારિત નિયંત્રણો અને માનવ મૂલ્યાંકનને સંપૂર્ણપણે છોડી દેવા જોઈએ
- ડી) ન્યાયાધીશના સ્કોર્સ માનવ-લેબલવાળા નમૂના સાથે માપાંકિત કરવા જોઈએ અને તેમના પર વિશ્વાસ કરી શકાય તે પહેલાં તેમના પૂર્વગ્રહને માપવામાં આવે છે ✔
વર્ણન: LLM-રેફરી પણ એક મોડેલ છે; તે ભ્રામક, પક્ષપાતી (લાંબા, આત્મવિશ્વાસપૂર્ણ જવાબોની તરફેણ કરનાર) અને અસંગત હોઈ શકે છે. તેથી, રેફરી સ્કોર્સને માનવ લેબલવાળા નમૂના સાથે માપાંકિત કરવું આવશ્યક છે અને ઉત્પાદનનો નિર્ણય લેવામાં આવે તે પહેલાં તેમના વ્યવસ્થિત પૂર્વગ્રહને માપવા આવશ્યક છે. ચકાસાયેલ રેફરી ખોટો વિશ્વાસ આપે છે.
14. મોડલના પૂર્વગ્રહનું મૂલ્યાંકન કરતી વખતે એકંદર ચોકસાઈ કેમ અપૂરતી છે?
- A) એકંદર ચોકસાઈ પૂરતી છે કારણ કે તે હંમેશા સૌથી ખરાબ જૂથના પ્રદર્શનને પ્રતિબિંબિત કરે છે
- બી) એકંદર ચોકસાઈ જ અપૂરતી છે કારણ કે તે પેટાજૂથો વચ્ચેના વ્યવસ્થિત તફાવત (છુપાયેલા ભેદભાવ)ને અસ્પષ્ટ કરી શકે છે ✔
- C) કારણ કે ચોકસાઈ એ એક મેટ્રિક છે જેને પૂર્વગ્રહ સાથે કોઈ લેવાદેવા નથી
- ડી) પૂર્વગ્રહ ફક્ત મોડેલમાંથી આવે છે અને ડેટા સાથે તેને કોઈ લેવાદેવા નથી.
સમજૂતી: એકંદર ચોકસાઈ પેટાજૂથો વચ્ચેના વ્યવસ્થિત તફાવતોને અસ્પષ્ટ કરી શકે છે. ઉદાહરણ તરીકે, જ્યારે એકંદર ચોકસાઈ 88% છે, ત્યારે રિકોલ એક જૂથમાં 91% અને બીજા જૂથમાં 67% હોઈ શકે છે; મોડેલ વ્યવસ્થિત રીતે તે જૂથને ચૂકી જાય છે. તેથી, મોડલનું મૂલ્યાંકન પેટાજૂથો (જનસંખ્યા/વિભાગ)ના આધારે થવું જોઈએ અને ન્યાયની કઈ વ્યાખ્યાને પ્રાધાન્ય આપવું જોઈએ તે હિસ્સેદારો સાથે નક્કી કરવું જોઈએ.
15. ML પરિણામ પુનઃઉત્પાદન કરી શકાય તે માટે કઈ ચાર બાબતો એકસાથે નિશ્ચિત કરવી જોઈએ?
- A) ફક્ત મોડેલનું નામ, કદ, કિંમત અને પ્રકાશન તારીખ
- B) માત્ર GPU બ્રાન્ડ અને ઇન્ટરનેટ સ્પીડ
- સી) મોડેલનો માત્ર અંતિમ ચોકસાઈનો સ્કોર; બાકીના મેમરીમાં રાખી શકાય છે
- ડી) રેન્ડમનેસ સીડ, ડેટા વર્ઝન, એન્વાયર્નમેન્ટ (ડિપેન્ડન્સી વર્ઝન) અને પ્રયોગ ટ્રેકિંગ ✔
વર્ણન: પ્રજનનક્ષમતા ચાર સ્તંભો દ્વારા પ્રાપ્ત થાય છે: રેન્ડમનેસ સીડ્સ ફિક્સિંગ, ડેટા વર્ઝનિંગ (સંસ્કરણ/હેશ), પર્યાવરણને ફ્રીઝ કરવું (ચોક્કસ લાઇબ્રેરી વર્ઝન/કન્ટેનર), અને દરેક પ્રયોગને ટ્રૅક કરવું (કોડ કમિટ, ડેટા, હાઇપરપેરામીટર, મેટ્રિક). આ સાંકળ વિના સમાન પરિણામનું પુનઃઉત્પાદન કરવું શક્ય નથી; બિન-પ્રજનનક્ષમ પરિણામ એ દાવો છે જે સાબિત કરી શકાતો નથી.