એન્ડ-ટુ-એન્ડ પ્રોડક્શન: વેરિફિકેશન, મોનિટરિંગ અને એથિક્સ

નફો:

• એન્ડ-ટુ-એન્ડ આર્કિટેક્ચરને ડિઝાઇન કરી શકે છે જે આઇડિયાથી પ્રોડક્શન સુધી એલએલએમ સુવિધા લે છે
• ચકાસણી અમલીકરણ, માનવ મંજૂરી અને ટ્રેકિંગના સ્તરો સ્થાપિત કરે છે (લોગિંગ/મેટ્રિક્સ)
• સીમાઓ નૈતિકતા અને ગોપનીયતા સિદ્ધાંતોને ઉત્પાદન નિર્ણયોમાં અનુવાદિત કરે છે

અગાઉના દસ એકમોમાં, અમે એક પછી એક ભાગો શીખ્યા: વિનંતી માળખું, ટોકન અર્થશાસ્ત્ર, પ્રવાહ, સિસ્ટમ પ્રોમ્પ્ટ, મોડેલ પસંદગી, કેશ, બેચ, એરર મેનેજમેન્ટ, સુરક્ષિત કી અને ઓટોમેશન. આ છેલ્લા એકમમાં, અમે ભાગોને જોડીએ છીએ અને સર્વગ્રાહી આર્કિટેક્ચરની સ્થાપના કરીએ છીએ જે આઈડિયાથી પ્રોડક્શન સુધી LLM સુવિધા ધરાવે છે. ઉત્પાદન "વર્કિંગ ડેમો" કરતા અલગ છે: ચકાસણી ફરજિયાત છે, આઉટપુટનું નિરીક્ષણ કરવું આવશ્યક છે, સીમાઓ અને નૈતિક સિદ્ધાંતો નિર્ણયોમાં એમ્બેડ કરેલા હોવા જોઈએ. આ એકમ એ મોડ્યુલનો વાહક કૉલમ છે; અગાઉના બધા અહીં ભેગા થાય છે.

ઉત્પાદન આર્કિટેક્ચરના સ્તરો

નક્કર LLM લાયકાતમાં આશરે પાંચ સ્તરો હોય છે:

1. ઇનપુટ લેયર: ડેટા એકત્રિત કરો, તેને સાફ કરો, સંવેદનશીલ વિસ્તારોને માસ્ક કરો, જરૂરી હોય તે જ ટ્રાન્સમિટ કરો.
2. મોડલ લેયર: યોગ્ય મોડલ (યુનિટ 5) પસંદ કરો, સિસ્ટમ પ્રોમ્પ્ટ અને પેરામીટર્સ (યુનિટ 4), કેશ (યુનિટ 6) સેટ કરો.
3. માન્યતા સ્તર: જો જરૂરી હોય તો સ્કીમા/નિયમ, સ્ત્રોત અને માનવ મંજૂરી સામે આઉટપુટ તપાસો.
4. ક્રિયા સ્તર: માન્ય આઉટપુટ સાથે ક્રિયા કરો; ઉચ્ચ અસર ક્રિયાઓ કેપ્ચર.
5. મોનિટરિંગ લેયર: દરેક કૉલ, કિંમત, ભૂલ અને ગુણવત્તાને રેકોર્ડ કરો અને માપો.

આ સ્તરો પાઇપલાઇન છે; દરેક એક પાછલા એકનું આઉટપુટ તપાસે છે.

ચકાસણી શા માટે જરૂરી છે?

એલએલએમ અસ્ખલિત પરંતુ ક્યારેક અચોક્કસ આઉટપુટ પેદા કરી શકે છે. આને આભાસ કહેવામાં આવે છે: મોડેલ એવી માહિતી બનાવી શકે છે જે સાચી લાગે છે પરંતુ નથી. ચેટ ગેમમાં આ સહ્ય છે; ઉત્પાદન પ્રણાલીમાં સહન કરી શકાતું નથી (ઇનવોઇસ, આરોગ્ય, કાનૂની, નાણા). તેથી તે બહાર આવ્યું, અંધપણે અવિશ્વસનીય; પુષ્ટિ થયેલ છે.

ચકાસણી સ્તરો (અસર દ્વારા વધતા):

• ફોર્મેટ/સ્કીમા માન્યતા: શું આઉટપુટ અપેક્ષિત JSON સ્કીમાને અનુરૂપ છે? (સંરચિત આઉટપુટ મોટે ભાગે આની ખાતરી આપે છે.)
• નિયમ/તર્ક ચકાસણી: શું મૂલ્યો વાજબી છે? (શું રકમ નકારાત્મક છે, શું ભવિષ્યની તારીખ છે, શું શ્રેણી માન્ય છે?)
• સ્ત્રોત ચકાસણી: શું દાવો પૂરા પાડવામાં આવેલ દસ્તાવેજો પર આધારિત છે? શું મોડેલ કંઈક એવું કહે છે જે દસ્તાવેજમાં નથી?
• માનવીય મંજૂરી: નિષ્ણાત ઉચ્ચ-અસરકારક અથવા અસ્પષ્ટ નિર્ણયોની સમીક્ષા કરે છે.

સાવધાન: "મોડેલ ખૂબ સારું છે, વધુ ચકાસણીની જરૂર નથી" એ સૌથી ખતરનાક ઉત્પાદન ભ્રમણા છે. મોડલ ગમે તેટલું સારું હોય, વેરિફિકેશન લેયર એ ઉચ્ચ અસરવાળા નિર્ણયોમાં સલામતીનું માળખું છે. એક ખોટો સ્વચાલિત નિર્ણય પણ બચેલો સમય કાઢી શકે છે.

માનવ-ઇન-ધ-લૂપ

દરેક નિર્ણય સંપૂર્ણ સ્વચાલિત હોવો જરૂરી નથી. માનવ-ઇન-ધ-લૂપ અભિગમમાં, મોડેલ કાર્યને ઝડપી બનાવે છે અને માનવ તેને મંજૂર કરે છે. યોગ્ય સંતુલન નિર્ણયની અસર અને તે કાર્ય પર મોડેલની વિશ્વસનીયતા પર આધારિત છે.

નિર્ણયની અસર

અભિગમ

ઓછું (લેબલ સૂચન, ડ્રાફ્ટ)

સંપૂર્ણ ઓટોમેશન; ભૂલ સસ્તી અને ઉલટાવી શકાય તેવી છે

માધ્યમ (રાઉટીંગ, પ્રાથમિકતા)

ઓટોમેશન + સેમ્પલિંગ નિયંત્રણ

ઉચ્ચ (પૈસા, કરાર, આરોગ્ય, કાઢી નાખવું)

માનવ સંમતિ ફરજિયાત છે; મોડેલ ફક્ત સૂચવે છે

મોનિટરિંગ: તમે જે જોતા નથી તે તમે મેનેજ કરી શકતા નથી

ઉત્પાદનમાં, તમારે દરેક કૉલનું નિરીક્ષણ કરવું આવશ્યક છે. મોનિટરિંગ વિના, તમે કિંમત, ગુણવત્તા સુધારી શકતા નથી અથવા સમસ્યાને વહેલા પકડી શકતા નથી. રેકોર્ડ કરવા માટેના મુખ્ય મેટ્રિક્સ:

• વપરાશ/કિંમત: વિનંતી દીઠ અને કુલ ટોકન્સ, મોડેલ વિતરણ, દૈનિક ખર્ચ.
• લેટન્સી: સરેરાશ અને સૌથી ખરાબ-કેસ પ્રતિભાવ સમય.
• ભૂલ દર: 429/500 દરો, ફરી પ્રયાસો, ત્યાગ.
• ગુણવત્તા: ચકાસણી સ્તર પર નકારેલ આઉટપુટ દર, માનવ મંજૂરી પર કરેક્શન દર, વપરાશકર્તા પ્રતિસાદ.

ટીપ: મોનિટરિંગ લોગ પર સંવેદનશીલ ડેટા (વ્યક્તિગત માહિતી, કી) લખશો નહીં. ગોપનીયતાના દાયરામાં લૉગ્સનો વિચાર કરો; જો જરૂરી હોય તો માસ્ક કરીને રેકોર્ડ કરો (એકમ 9).

નીતિશાસ્ત્ર અને સીમાઓ

નૈતિક જવાબદારી એ ઉત્પાદન નિર્ણયનો તેટલો જ એક ભાગ છે જેટલો તકનીકી ચોકસાઈ છે:

• પારદર્શિતા: વપરાશકર્તાને ખબર હોવી જોઈએ કે તેઓ કૃત્રિમ બુદ્ધિમત્તા સાથે વાત કરી રહ્યા છે કે માનવ સાથે.
• નિષ્પક્ષતા અને પૂર્વગ્રહ: મોડેલ તે ડેટામાંથી પૂર્વગ્રહ ધરાવી શકે છે જેના પર તેને તાલીમ આપવામાં આવી છે; ઉચ્ચ અસરવાળા નિર્ણયો (ભાડે, ક્રેડિટ) માં ભેદભાવપૂર્ણ પરિણામોનું નિરીક્ષણ કરો.
• જવાબદારી: જો સ્વયંસંચાલિત નિર્ણયથી નુકસાન થાય છે, તો તમે જવાબદાર છો; "મોડેલે આમ કહ્યું" એ સંરક્ષણ નથી.
• મર્યાદાઓની સ્વીકૃતિ: મોડેલ કેટલાક કાર્યો વિશ્વસનીય રીતે કરી શકતું નથી; તેમને સ્વચાલિત ન કરવું એ પણ ડિઝાઇન નિર્ણય છે.

નકલ કરી શકાય તેવા નમૂનાઓ

# માન્યતા ચેકલિસ્ટ (આઉટપુટ જનરેશન પછી)1) શું સ્કીમા માન્ય છે? (સંરચિત આઉટપુટ માન્યતા)2) શું મૂલ્યો અર્થપૂર્ણ છે? (નિયમ તપાસ: શ્રેણી, તારીખ, enum)3) શું દાવો સ્ત્રોત પર આધારિત છે? (દસ્તાવેજમાં ન હોય તો નામંજૂર કરો)4) શું અસર વધારે છે? → માનવ મંજૂરી માટે મોકલો5) જો બધું પાસ થઈ જાય → ક્રિયાને મંજૂરી આપો, સાચવો

# સિસ્ટમ પ્રોમ્પ્ટ કે જે સ્ત્રોત પર આધાર રાખવા માટે દબાણ કરે છે, ફક્ત પ્રદાન કરેલ દસ્તાવેજમાંની માહિતી પર આધાર રાખે છે. દસ્તાવેજમાં ન હોય તેવી કોઈ પણ વસ્તુ ઉમેરશો નહીં. જો કોઈ માહિતી દસ્તાવેજમાં નથી, તો "દસ્તાવેજમાં મળ્યું નથી" લખો. ક્યારેય અનુમાન ન કરો અથવા વસ્તુઓ બનાવો.

# માનવ મંજૂરી થ્રેશોલ્ડ (નિર્ણયનો નિયમ) IF [પૈસા, કરાર, કાઢી નાખો, આરોગ્ય] માં નિર્ણય_પ્રકાર

# ટ્રેસ લોગ ટેમ્પલેટ (સંવેદનશીલ ડેટા લખવાનું) { "સમય":"...", "મોડેલ":"...", "ઇનપુટ_ટોકન":..., "આઉટપુટ_ટોકન":..., "વિલંબ_એમએસ":..., "સ્ટોપ_રીઝન":"...", "ઓથેન્ટિકેશન":"પાસ થયેલ| અસ્વીકાર| માનવ" // } કી લખાયેલ છે અને વ્યક્તિગત ડેટા છે ...

નબળા પ્રોમ્પ્ટ / મજબૂત પ્રોમ્પ્ટ (ઉત્પાદન વિશ્વસનીયતા)

# નબળું (કોઈ ચકાસણી, કોઈ સ્ત્રોત નથી, આપમેળે લાગુ થાય છે) આ વિનંતીનું મૂલ્યાંકન કરો, રિફંડનો નિર્ણય લો અને અરજી કરો.

# સ્ટ્રોંગ (સ્રોત-આધારિત, ભલામણ જનરેટ કરે છે, માનવીય મંજૂરી માટે છોડી દે છે) માત્ર વળતર નીતિ દસ્તાવેજના આધારે આ વળતર વિનંતીનું મૂલ્યાંકન કરો. વાજબીતા સાથે નિર્ણયની ભલામણ કરો પરંતુ અમલ કરશો નહીં: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}. જો પોલિસી દસ્તાવેજમાં કોઈ સ્પષ્ટ આધાર ન હોય તો, "અસ્પષ્ટ" આપો. એક પ્રતિનિધિ અંતિમ નિર્ણયને મંજૂરી આપશે.

શક્તિશાળી સંસ્કરણ; તે સ્ત્રોતને નિર્ણયનું શ્રેય આપે છે, મોડેલને "કરનાર" ને બદલે "સૂચનકર્તા" તરીકે સ્થાન આપે છે અને માનવીય મંજૂરી પાછળ ઉચ્ચ-અસરકારક પગલું મૂકે છે. આ ઉત્પાદનની વિશ્વસનીયતાનો સાર છે.

ત્રણ મિની કેસ

કેસ 1 — જે દિવસે વેરિફિકેશન લેયર સેવ થયું. ફિનટેક પાસે મોડેલનું વર્ગીકરણ ટ્રાન્ઝેક્શન વર્ણનો અને સ્વચાલિત એકાઉન્ટિંગ રેકોર્ડ્સ હતા. તેઓએ નિયમ માન્યતા ઉમેર્યું: એકવાર મોડલ રકમ ખોટી રીતે આઉટપુટ કરે છે (દસ્તાવેજમાં 1,250 ને બદલે 12,500), "રકમ દસ્તાવેજ સાથે મેળ ખાતી નથી" નિયમએ આઉટપુટને નકારી કાઢ્યું અને રેકોર્ડ માનવને પડ્યો. જો ત્યાં કોઈ ચકાસણી ન હોય, તો ખોટો રેકોર્ડ ચુપચાપ સિસ્ટમમાં દાખલ થશે.

કેસ 2 - સર્વેલન્સ દ્વારા પકડાયેલ ભાગેડુ. SaaS ટીમે મોનિટરિંગ પેનલની સ્થાપના કરી હતી; એક સવારે રોજનો ખર્ચ ત્રણ ગણો વધી ગયો. લૉગ્સમાંથી એવું જોવામાં આવ્યું હતું કે એક ક્લાયન્ટે લૂપમાં પ્રવેશ કર્યો અને હજારો વખત તે જ વિનંતી મોકલી. તેઓએ ક્વોટા અને ડુપ્લિકેશન ઉમેર્યા; કલાકોમાં સમસ્યા ઉકેલાઈ હતી. ટ્રેકિંગ વિના, મહિનાના અંતે બિલ આશ્ચર્યજનક હશે.

કેસ 3 - મર્યાદા સ્વીકારવી. હેલ્થકેર સ્ટાર્ટઅપ સંપૂર્ણ રીતે આપમેળે નિદાનની ભલામણ કરવા અને દર્દીને બતાવવાનું આયોજન કરી રહ્યું હતું. નૈતિકતા અને જવાબદારીની સમીક્ષામાં, તેઓએ નક્કી કર્યું કે આ મર્યાદાની બહાર છે: મોડેલ માત્ર એક ચિકિત્સકને સારાંશ અને સંભવિત મુદ્દાઓ પ્રદાન કરે છે, ચિકિત્સક નિદાન કરે છે. નોકરીને સ્વચાલિત ન કરવી એ પણ પરિપક્વ ડિઝાઇન નિર્ણય છે.

સામાન્ય ભૂલો

• માન્યતા છોડવી: "મોડલ સારું છે" એમ કહીને આંખ બંધ કરીને આઉટપુટ લાગુ કરવું.
• સ્વચાલિત ઉચ્ચ-અસર નિર્ણય: પૈસા/આરોગ્ય/કાયદામાં માનવીય મંજૂરી જરૂરી છે.
• મોનિટરિંગ નથી: ખર્ચ અને ગુણવત્તા સમસ્યાઓ મોડેથી મળી આવે છે.
• લૉગમાં સંવેદનશીલ ડેટા લખવું: ગોપનીયતાનું ઉલ્લંઘન; તેને માસ્ક કરીને સાચવો.
• સ્ત્રોત પર આધાર રાખવાનો પ્રયાસ ન કરવો: દસ્તાવેજમાં જે નથી તે મોડેલ બનાવી શકે છે.
• મર્યાદાઓને અવગણવી: અમુક કાર્યોને સ્વચાલિત ન કરવું એ યોગ્ય નિર્ણય છે; પારદર્શિતા અને જવાબદારી તમારી છે.

ડીપર: રીલીઝ મેનેજમેન્ટ, રોલબેક અને ઇન્ક્રીમેન્ટલ ડિપ્લોયમેન્ટ

ઉત્પાદનમાં LLM સુવિધા લેવી એ તેને સેટ કરવા અને તેના વિશે ભૂલી જવા વિશે નથી; સમય જતાં જીવંત સિસ્ટમને સુરક્ષિત રીતે સંશોધિત કરવાનો છે. તેમાં ત્રણ થાંભલા છે.

વર્ઝનીંગ. તમારી સિસ્ટમ પ્રોમ્પ્ટ, મોડેલ પસંદગી અને ચકાસણી નિયમો સમય સાથે બદલાય છે. દરેક નોંધપાત્ર ફેરફારનું સંસ્કરણ કરો અને કયું સંસ્કરણ લાઇવ છે તે રેકોર્ડ કરો. જો એક દિવસ ગુણવત્તા ઘટી જાય, "અમે શું બદલ્યા?" તમે મિનિટોમાં પ્રશ્નનો જવાબ આપવા સક્ષમ હોવા જોઈએ. વર્ઝનલેસ સિસ્ટમમાં, રીગ્રેસનનું મૂળ કારણ શોધવામાં દિવસો લાગે છે.

રોલબેક. જો નવો પ્રોમ્પ્ટ અથવા મોડલ લાઇવમાં અપેક્ષિત કરતાં વધુ ખરાબ વર્તન કરે છે, તો તમે ઝડપથી અગાઉના, જાણીતા સંસ્કરણ પર પાછા ફરવા માટે સમર્થ હોવા જોઈએ. રોલબેક પ્લાન વિના ફેરફાર એ જીવંત જોખમને આંખ આડા કાન કરે છે. "મેં કંઈક બદલ્યું છે, તે ખરાબ થઈ ગયું છે, હું પાછો જઈ શકતો નથી" એ સૌથી ખર્ચાળ ઉત્પાદન દૃશ્ય છે.

ક્રમિક રોલઆઉટ. એક જ સમયે તમામ ટ્રાફિકમાં ફેરફાર લાગુ કરવાને બદલે, તમે તેને નાની ટકાવારીમાં (દા.ત. 5%) પહેલા રોલ આઉટ કરો અને મેટ્રિક્સ (ગુણવત્તા, કિંમત, ભૂલો)નું નિરીક્ષણ કરો. જો તે સારું છે, તો તમે ટકાવારીમાં વધારો કરો છો; જો તે ખરાબ છે, તો તમને અસરગ્રસ્ત નાના વિભાગ સાથે જ તે પાછું મળશે. આ જોખમને મોટા પ્રમાણમાં મર્યાદિત કરે છે.

આ ત્રણ પ્રથાઓ અગાઉના તમામ એકમોની તકનીકોને જોડે છે: eval (એકમ 5) અગાઉથી ફેરફારોને માપે છે, મોનિટરિંગ (આ એકમ) પ્રચાર દરમિયાન પ્રારંભિક ચેતવણી આપે છે, ચકાસણી સ્તર કાર્યવાહી કરવા યોગ્ય બને તે પહેલાં ભૂલભરેલા આઉટપુટને પકડે છે. ઉત્પાદન એક યોગ્ય સેટઅપ નથી; તે એક સતત શિસ્ત છે જે માપે છે, મોનિટર કરે છે અને આત્મવિશ્વાસ સાથે બદલી શકે છે. આ શિસ્ત સ્થાપિત કરવા માટે આખું મોડ્યુલ તમારા માટે છે.

સારાંશમાં

ઉત્પાદન કાર્યકારી ડેમો કરતાં વધુ છે: તે ઇનપુટ, મોડેલ, ચકાસણી, ક્રિયા અને મોનિટરિંગ સ્તરોની પાઇપલાઇન છે. ચકાસણી વિના આઉટપુટ અવિશ્વસનીય છે; ઉચ્ચ અસરવાળા નિર્ણયો માનવ મંજૂરી સાથે જોડાયેલા છે; ખર્ચ, ભૂલો અને ગુણવત્તા માટે દરેક કોલ પર નજર રાખવામાં આવે છે. નૈતિકતા, પારદર્શિતા, પૂર્વગ્રહ નિયંત્રણ, જવાબદારી અને મર્યાદાની સ્વીકૃતિ તકનીકી નિર્ણયો માટે અભિન્ન છે. આ મોડ્યુલમાં શીખેલ દરેક ભાગ આ સર્વગ્રાહી ડિઝાઇનમાં એકસાથે આવે છે.

એપ્લિકેશન કાર્ય

એક LLM સુવિધા એન્ડ-ટુ-એન્ડ ડિઝાઇન કરો. (1) તમારા ચોક્કસ કાર્ય માટે પાંચ સ્તરો (ઇનપુટ, મોડેલ, વેરિફિકેશન, એક્શન, મોનિટરિંગ) ભરો. (2) અસર દ્વારા ચિહ્નિત કરો કે કયા નિર્ણયોને માનવીય મંજૂરીની જરૂર પડશે. (3) ઓછામાં ઓછા ત્રણ માન્યતા તપાસો (સ્કીમા, નિયમ, સ્ત્રોત) લખો. (4) તમે કયા મુખ્ય મેટ્રિક્સને ટ્રૅક કરશો અને તમે શું લૉગ કરશો નહીં તે નક્કી કરો. (5) એક મર્યાદા અને નૈતિક સિદ્ધાંત લખો જે તમે આ સુવિધામાં સ્વીકારો છો.

ચેકલિસ્ટ

• [ ] હું ઉત્પાદન પાઇપલાઇનના પાંચ સ્તરો ડિઝાઇન કરી શકું છું.
• [ ] હું સ્કીમા, નિયમ અને સ્ત્રોત સામે આઉટપુટને માન્ય કરી શકું છું.
• [ ] હું નિર્ણયની અસરના આધારે માનવ મંજૂરીની મર્યાદા નક્કી કરી શકું છું.
• [ ] હું ખર્ચ, ભૂલ અને ગુણવત્તા પર નજર રાખું છું અને લોગમાં સંવેદનશીલ ડેટા ન લખવાની પ્રેક્ટિસ કરું છું.
• [] હું નીતિશાસ્ત્ર, જવાબદારી અને સીમાઓને ઉત્પાદન નિર્ણયોમાં પરિવર્તિત કરી શકું છું.

મોડ્યુલ પરીક્ષા

1. LLM ચેટ API માં 'સિસ્ટમ' ભૂમિકા શું કરે છે?

• A) મોડેલને કાયમી સૂચનાઓ અને વર્તનના નિયમો આપે છે જે સમગ્ર વાતચીત દરમિયાન લાગુ પડે છે ✔
• બી) વપરાશકર્તા દ્વારા લખાયેલ છેલ્લો પ્રશ્ન રાખે છે
• સી) મોડેલ દ્વારા ઉત્પાદિત પ્રતિભાવને સંગ્રહિત કરે છે
• ડી) API કીને એન્ક્રિપ્ટ કરે છે

વર્ણન: સિસ્ટમની ભૂમિકા મોડેલને સતત સૂચનાઓ, વ્યક્તિત્વ અને નિયમો આપે છે જે સમગ્ર વાતચીત દરમિયાન લાગુ પડે છે; તે ઉચ્ચ સ્તરીય રીડાયરેક્ટ છે, જે વપરાશકર્તા સંદેશાઓથી અલગ છે.

2. દરેક વખતે API વિનંતીમાં વાતચીતનો ઇતિહાસ (અગાઉના સંદેશા) શા માટે ફરીથી મોકલવામાં આવે છે?

• A) સર્વર હિસ્ટ્રી ડિલીટ કરે તે રીતે બેકઅપ લેવો જરૂરી છે
• બી) API કૉલ સ્ટેટલેસ છે; ✔ દરેક વિનંતી પર સંદર્ભ મોકલવામાં આવે છે કારણ કે મોડેલ ઇતિહાસ યાદ રાખતું નથી
• સી) માત્ર ઇન્વોઇસિંગ માટે જરૂરી, મોડેલ પર કોઈ અસર થતી નથી
• ડી) પ્રતિભાવ ધીમો ન થાય તે માટે ઇતિહાસ મોકલવો ફરજિયાત છે

સમજૂતી: LLM API કૉલ સ્ટેટલેસ છે; મોડેલ અગાઉના રાઉન્ડને યાદ રાખતું નથી, તેથી સંદર્ભ સાચવવાની દરેક વિનંતી પર તમામ સંબંધિત ઇતિહાસ ફરીથી મોકલવામાં આવે છે.

3. LLM કિંમતમાં 'ટોકન' શું છે?

• A) API માં લૉગ ઇન કરવા માટે વપરાતો વન-ટાઇમ પાસવર્ડ
• બી) દરેક વિનંતી પર નિશ્ચિત ફી ચૂકવવામાં આવે છે
• સી) સૌથી નાનું એકમ જેમાં મોડેલ ટેક્સ્ટ પર પ્રક્રિયા કરે છે; સામાન્ય રીતે શબ્દ ભાગ ✔ ને અનુલક્ષે છે
• ડી) એક એકમ જે માત્ર આઉટપુટની લંબાઈને માપે છે

વર્ણન: ટોકન એ સૌથી નાનું એકમ છે જેમાં મોડેલ ટેક્સ્ટ પર પ્રક્રિયા કરે છે; તે સામાન્ય રીતે શબ્દના ટુકડાને અનુરૂપ હોય છે, અને ઇનપુટ અને આઉટપુટ બંને ટોકન્સની સંખ્યાના આધારે ચાર્જ કરવામાં આવે છે.

4. મોટાભાગના LLM પ્રદાતાઓ પર ઇનપુટ ટોકન્સ કરતાં આઉટપુટ ટોકન્સ વધુ મોંઘા કેમ છે?

• A) આઉટપુટ ટોકન્સ હંમેશા ઇનપુટ કરતા લાંબા હોય છે
• બી) ઇનપુટ ટોકન્સ મફત છે
• C) આઉટપુટ ટોકન્સ ઇન્ટરનેટ પર બે વાર મોકલવામાં આવે છે
• ડી) યુનિટની કિંમત વધારે છે કારણ કે આઉટપુટ જનરેશન માટે દરેક ટોકન માટે વધારાની ગણતરીની જરૂર પડે છે ✔

વર્ણન: દરેક આઉટપુટ ટોકન્સ માટે મોડેલને સ્ટેપ-બાય-સ્ટેપ જનરેશન (ગણતરી) કરવાની જરૂર છે; આ ઉત્પાદન ખર્ચ એક જ સમયે ઇનપુટ પર પ્રક્રિયા કરવા કરતાં વધારે છે, તેથી આઉટપુટ યુનિટની કિંમત સામાન્ય રીતે વધારે હોય છે.

5. કઈ પરિસ્થિતિમાં સ્ટ્રીમિંગનો ઉપયોગ કરવો સૌથી વધુ ફાયદાકારક છે?

• એ) લાંબા જવાબોમાં; કથિત વિલંબ ઘટાડે છે અને સમયસમાપ્તિ અટકાવે છે ✔
• બી) ફક્ત ખૂબ જ ટૂંકા, એક-શબ્દના જવાબો
• સી) ખર્ચને શૂન્ય સુધી ઘટાડવા માટે
• ડી) API કી છુપાવવા માટે

વર્ણન: લાંબા પ્રતિસાદોમાં, સ્ટ્રીમિંગ પ્રથમ શબ્દોને તરત જ દેખાડીને માનવામાં આવતી વિલંબતાને ઘટાડે છે અને મોટા max_tokens મૂલ્યો પર HTTP સમયસમાપ્તિને અટકાવે છે.

6. આધુનિક મોડેલોમાં 'પ્રયાસ' પરિમાણમાં વધારો સામાન્ય રીતે શું અસર કરે છે?

• A) જવાબ હંમેશા ટૂંકો કરો
• બી) API કીને આપમેળે ફેરવે છે
• સી) તે ફક્ત ઇનપુટ ટોકન કિંમત ઘટાડે છે
• ડી) વિચારની ઊંડાઈ અને ટોકન ખર્ચમાં વધારો કરે છે; તે ગુણવત્તામાં સુધારો કરી શકે છે, પરંતુ તે લેટન્સી અને ખર્ચમાં પણ વધારો કરે છે ✔

વર્ણન: પ્રયાસ પરિમાણ સમાયોજિત કરે છે કે મોડેલ કાર્ય વિશે કેટલું ઊંડાણપૂર્વક વિચારશે અને તે કેટલા ટોકન્સ ખર્ચ કરશે; અપગ્રેડ કરવાથી ગુણવત્તામાં સુધારો થઈ શકે છે, પરંતુ તે લેટન્સી અને ખર્ચમાં પણ વધારો કરે છે. સરળ કાર્યો માટે, ઓછી મહેનત પૂરતી છે.

7. સામાન્ય રીતે સરળ, ઉચ્ચ-વોલ્યુમ વર્ગીકરણ કાર્ય માટે સૌથી વધુ ખર્ચ-અસરકારક અભિગમ શું છે?

• A) હંમેશા સૌથી મોંઘા અને સૌથી શક્તિશાળી મોડલનો ઉપયોગ કરો
• બી) દરેક વિનંતિ માટે એક જ સમયે તમામ મોડેલોને કૉલ કરવો
• C) સૌથી હલકું/સસ્તું મોડલ પસંદ કરવું જે કાર્યને થોડું ઇવેલ સાથે ચકાસીને પૂર્ણ કરે છે ✔
• ડી) મહત્તમ_ટોકન્સ મૂલ્યને બિનજરૂરી રીતે ખૂબ વધારે રાખવું

સમજૂતી: જો કાર્ય જટિલ ન હોય, તો સૌથી મોંઘા અને શક્તિશાળી મોડલનો ઉપયોગ કરવાને બદલે ઝડપી અને સસ્તું મોડલ પસંદ કરવું જે સરળતાથી કાર્ય પૂર્ણ કરે (દા.ત. હાઈકુ વર્ગ) ખર્ચમાં નોંધપાત્ર ઘટાડો કરશે.

8. કયા સંજોગોમાં પ્રોમ્પ્ટ કેશીંગ સૌથી વધુ ખર્ચ ઘટાડે છે?

• A) જ્યારે ઘણી બધી વિનંતીઓમાં મોટા અને નિશ્ચિત સંદર્ભનો વારંવાર ઉપયોગ કરવામાં આવે છે ✔
• બી) જ્યારે દરેક વિનંતી સાથે સંપૂર્ણપણે અલગ ટેક્સ્ટ મોકલવામાં આવે છે
• સી) જ્યારે માત્ર એક જ વિનંતી કરવામાં આવે છે
• ડી) આઉટપુટ ટોકન્સ ઘટાડવા માટે

વર્ણન: કેશીંગ એ ઉપસર્ગ મેચ છે; એવા કિસ્સામાં જ્યાં મોટા, અપરિવર્તનશીલ સંદર્ભ (સિસ્ટમ પ્રોમ્પ્ટ, દસ્તાવેજો) નો ઘણી બધી વિનંતીઓમાં પુનઃઉપયોગ કરવામાં આવે છે, કેશમાંથી વાંચન એ સંપૂર્ણ કિંમતનો એક નાનો અપૂર્ણાંક (~0.1x) છે.

9. મારે પ્રોમ્પ્ટને કેવી રીતે સંપાદિત કરવું જોઈએ જેથી કરીને પ્રોમ્પ્ટ કેશ હિટ થાય?

• A) ચલ સામગ્રીને શરૂઆતમાં અને નિશ્ચિત સામગ્રીને અંતે મૂકવી
• બી) દરેક વિનંતી માટે સિસ્ટમ પ્રોમ્પ્ટમાં વર્તમાન તારીખ અને સમય એમ્બેડ કરો
• સી) શરૂઆતમાં નિશ્ચિત સામગ્રી (સિસ્ટમ પ્રોમ્પ્ટ, દસ્તાવેજો) અને અંતમાં ચલ સામગ્રી મૂકવી ✔
• ડી) દરેક વિનંતી સાથે સાધન સૂચિનો ક્રમ બદલવો

સમજૂતી: કેશ એ ઉપસર્ગ મેચ હોવાથી, નિશ્ચિત/અપરિવર્તનશીલ સામગ્રી (સિસ્ટમ પ્રોમ્પ્ટ, દસ્તાવેજો) પ્રારંભ કરવામાં આવે છે; ચલ સામગ્રી (તારીખ, વપરાશકર્તા પ્રશ્ન, વિનંતી ID) અંતમાં મૂકવામાં આવે છે. શરૂઆતમાં બદલાયેલ એક બાઈટ પણ કેશને અમાન્ય કરશે.

10. કયા પ્રકારના વર્કલોડ માટે બેચ પ્રોસેસિંગ સૌથી યોગ્ય છે?

• A) લાઇવ ચેટ જ્યાં વપરાશકર્તા સ્ક્રીન પર ત્વરિત પ્રતિસાદની અપેક્ષા રાખે છે
• બી) માત્ર એક ટૂંકો પ્રશ્ન
• સી) API કી જનરેટ કરી રહ્યું છે
• ડી) નોકરીઓ જે વિલંબ સહન કરે છે, મોટા પ્રમાણમાં હોય છે અને તાત્કાલિક પરિણામોની જરૂર નથી ✔

વર્ણન: બેચ પ્રોસેસિંગ મોટી સંખ્યામાં નોકરીઓ માટે યોગ્ય છે જેને તાત્કાલિક પ્રતિસાદની જરૂર નથી અને વિલંબને સહન કરી શકે છે; પરિણામો થોડા સમય પછી વિતરિત કરવામાં આવે છે, પરંતુ એકમની કિંમત સામાન્ય રીતે ઓછી હોય છે.

11. બેચના પરિણામો કઈ વિનંતી સાથે વિશ્વાસપૂર્વક મેચ કરવા માટે શું વપરાય છે?

• A) વિનંતીઓનો ઓર્ડર (સ્થિતિ) મોકલવો
• બી) જવાબોની લંબાઈ
• C) API કીના છેલ્લા 4 અંકો
• D) દરેક વિનંતીને આપવામાં આવેલ એક અનન્ય કસ્ટમ_id ✔

ટિપ્પણી: બલ્ક પરિણામો સબમિશન ઓર્ડર કરતાં અલગ ક્રમમાં પરત કરી શકાય છે; તેથી દરેક વિનંતિ માટે આપવામાં આવેલ અનન્ય કસ્ટમ_id સાથે, સ્થાન દ્વારા નહીં, ID દ્વારા પરિણામોનો મેળ કરવો જરૂરી છે.

12. જ્યારે તમને API તરફથી 429 (દર મર્યાદા) ભૂલ મળે ત્યારે ભલામણ કરેલ વર્તન શું છે?

• A) એક જ સમયે ઘણી વધુ વિનંતીઓ મોકલીને દબાણ કરવું
• B) ઘાતાંકીય બેકઓફ સાથે ફરીથી પ્રયાસ કરી રહ્યા છીએ, ફરીથી પ્રયાસ-આફ્ટર હેડિંગ ✔ને અનુસરીને
• સી) વિનંતીને સંપૂર્ણપણે રદ કરો અને વપરાશકર્તાને ક્રેશ તરીકે ભૂલ બતાવો
• ડી) API કી બદલવી

સમજૂતી: 429 એ ફરી પ્રયાસ કરી શકાય તેવી ભૂલ છે; સાચો અભિગમ એ છે કે ઘાતાંકીય બેકઓફ સાથે ફરી પ્રયાસ કરવો, ફરીથી પ્રયાસ-આફ્ટર હેડરને માન આપીને. મોટાભાગના સત્તાવાર SDK આ આપમેળે કરે છે.

13. નીચેનામાંથી કયા HTTP એરર કોડને સામાન્ય રીતે ફરીથી પ્રયાસ કરવા યોગ્ય ગણવામાં આવે છે?

• A) 400 (અમાન્ય વિનંતી)
• B) 401 (પ્રમાણીકરણ ભૂલ)
• C) 529 (સર્વર ઓવરલોડેડ) ✔
• ડી) 404 (મળ્યું નથી)

સમજૂતી: 429 (સ્પીડ લિમિટ), 500 (સર્વર એરર) અને 529 (ઓવરલોડ) એ કામચલાઉ ભૂલો છે અને બેક ઓફ કરીને ફરી પ્રયાસ કરી શકાય છે. 400 અને 401 જેવી ભૂલો વિનંતી/ઓળખની સમસ્યાઓ છે; ફરી પ્રયાસ કરવાથી તે ઉકેલાશે નહીં.

14. API કી મેનેજ કરવા માટે નીચેનામાંથી કઈ સુરક્ષિત રીત છે?

• એ) એન્વાયર્નમેન્ટ વેરીએબલ/હિડન મેનેજરમાં સ્ટોર કરવું, તેને કોડમાં એમ્બેડ ન કરવું અને નિયમિતપણે ફેરવવું ✔
• બી) કીને સીધી સોર્સ કોડમાં લખો અને તેને રીપોઝીટરીમાં મોકલો
• C) ક્લાયંટ બાજુ (બ્રાઉઝર) JavaScript માં કી મૂકવી
• ડી) ઈમેલ દ્વારા સમગ્ર ટીમ સાથે એક જ કી શેર કરવી

વર્ણન: કી ક્યારેય સોર્સ કોડ અથવા રીપોઝીટરી પર લખવામાં આવતી નથી; તે પર્યાવરણ ચલ અથવા છુપાયેલા મેનેજમેન્ટ ટૂલમાં સંગ્રહિત થાય છે, જે ન્યૂનતમ વિશેષાધિકારો સાથે આપવામાં આવે છે અને નિયમિતપણે ફેરવાય છે.

15. ગોપનીયતાના સંદર્ભમાં ઓટોમેશન ટૂલ (n8n, Zapier, Make) સાથે LLM એકીકરણ માટે શ્રેષ્ઠ અભિગમ શું છે?

• A) મોડલ પર તમામ કાચો ડેટા મોકલવો, પછી ભલે તે જરૂરી ન હોય
• બી) ફ્લો સ્ટેપની અંદર સાદા ટેક્સ્ટમાં API કી લખવી
• C) સંવેદનશીલ ડેટાને ન્યૂનતમ અને માસ્ક કરવો અને કીને ગુપ્ત ઓળખપત્ર તરીકે સંગ્રહિત કરવી ✔
• ડી) વ્યક્તિગત ડેટાને પ્રવાહ ઇતિહાસમાં કાયમી ધોરણે રાખવો

વર્ણન: ઓટોમેશનમાં દાખલ થતો ડેટા તૃતીય-પક્ષ સિસ્ટમ્સ અને મોડલમાંથી પસાર થાય છે, સંવેદનશીલ/વ્યક્તિગત ડેટાને ન્યૂનતમ, માસ્ક અને માત્ર જરૂરી ફીલ્ડ મોકલવાની જરૂર છે; API કી ટૂલની અંદર ગુપ્ત ઓળખપત્ર તરીકે પણ સંગ્રહિત છે.

16. એલએલએમ આધારિત ઉત્પાદન સુવિધામાં આઉટપુટની માન્યતા શા માટે ફરજિયાત છે?

• A) માત્ર ફોર્મેટિંગ જરૂરી છે કારણ કે મોડેલ ક્યારેય ભૂલ કરતું નથી
• બી) કારણ કે મોડેલ પ્રવાહી રીતે ઉત્પન્ન કરી શકે છે પરંતુ કેટલીકવાર ખોટી રીતે; સ્કીમા/નિયમનું ઓડિટ સંસાધન અને માનવીય મંજૂરી સાથે થવું જોઈએ ✔
• સી) માન્યતા ટાળવી જોઈએ કારણ કે તે માત્ર ખર્ચમાં વધારો કરે છે
• ડી) ચકાસણી માત્ર ટોકન્સની સંખ્યા ઘટાડવા માટે છે

વર્ણન: એલએલએમ અસ્ખલિત પરંતુ ક્યારેક અચોક્કસ (ભ્રામક) આઉટપુટ ઉત્પન્ન કરી શકે છે; તેથી તે ઉચ્ચ પ્રભાવના નિર્ણયોમાં બહાર આવ્યું; જ્યારે જરૂરી હોય ત્યારે સ્કીમા/નિયમોની ચકાસણી, સ્ત્રોત માન્યતા અને માનવ મંજૂરી દ્વારા તેનું ઓડિટ થવું જોઈએ.