ઇવલ અને મોનિટરિંગ: ઉત્પાદનમાં મોડેલ ખરેખર શું કરે છે તે જાણવું

નફો:

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

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

શા માટે ઉત્પાદન મોડલ શાંતિથી તૂટી રહ્યું છે

બગ ક્રેશ થાય છે, લોગ પ્રિન્ટ થાય છે, એલાર્મ બંધ થાય છે. બીજી બાજુ, ML મોડેલ ભૂલો કર્યા વિના ખોટું હોઈ શકે છે. અધોગતિના ત્રણ મુખ્ય કારણો:

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

ટ્રેસિંગ આ શાંત વિકૃતિઓને સાંભળી શકાય તેવું બનાવે છે.

શું જોવું: ત્રણ સ્તરો

સારી દેખરેખ ત્રણ સ્તરોને આવરી લે છે:

1. ઓપરેશનલ મેટ્રિક્સ: લેટન્સી, એરર રેટ, રિક્વેસ્ટ વોલ્યુમ, રિસોર્સ યુઝ. "શું સિસ્ટમ ઉભી છે?"
2. ડેટા/ઇનપુટ મેટ્રિક્સ: શું ઇનપુટ વિતરણ તાલીમમાં સમાન છે? શું ખૂટતા મૂલ્ય દરમાં વધારો થયો છે? શું નવી શ્રેણીઓ આવી છે? "શું મોડેલ પરિચિત ડેટા જોઈ રહ્યું છે?"
3. મોડલ/આઉટપુટ મેટ્રિક્સ: અનુમાન વિતરણ લોગ? શું આત્મવિશ્વાસનો સ્કોર ઘટી ગયો છે? અને જો શક્ય હોય તો, જમીની સત્યની સરખામણીમાં સચોટતા શું છે? "શું મોડેલ હજી પણ સચોટ છે?"

ત્રીજું સ્તર સૌથી મૂલ્યવાન છે પરંતુ સૌથી મુશ્કેલ છે; કારણ કે વાસ્તવિક પરિણામ સામાન્ય રીતે વિલંબ સાથે આવે છે (લોન ચૂકવવામાં આવશે કે નહીં તે મહિનાઓ પછી સ્પષ્ટ થાય છે).

ટીપ: જો વાસ્તવિક પરિણામમાં વિલંબ થાય, તો પહેલા ઇનપુટ અને અનુમાન વિતરણનું નિરીક્ષણ કરો. ઇનપુટ વિતરણનું શિફ્ટ એ ચોકસાઈના અધોગતિનું પ્રારંભિક સંકેત છે અને વાસ્તવિક પરિણામની રાહ જોયા વિના એલાર્મ વધારી શકે છે.

એલએલએમ સિસ્ટમ્સનું મૂલ્યાંકન: ખાસ પડકાર

ક્લાસિકલ ML માં, "સાચો જવાબ" સ્પષ્ટ છે (વર્ગ 0 અથવા 1). LLM પરિણામ, બીજી બાજુ, ઓપન-એન્ડેડ છે: એક જ પ્રશ્નના ઘણા સાચા જવાબો હોઈ શકે છે, "ચોક્કસતા" એક નંબરમાં બંધ બેસતી નથી. એલએલએમ ઇવલ અભિગમો:

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

વ્યવહારમાં આનો એકસાથે ઉપયોગ થાય છે: દરેક આઉટપુટ પર સસ્તા નિયમની તપાસ, મોટા નમૂના પર એલએલએમ-જજ, નાના પરંતુ સખત નમૂના પર માનવ મૂલ્યાંકન.

નબળા અભિગમ / મજબૂત અભિગમ

નબળા: "LLM-મેં રેફરીને પૂછ્યું, અમારા 92% જવાબો સારા હતા. સિસ્ટમ સરસ છે."

Güçlü: "અમે સૌપ્રથમ 100 પ્રિન્ટઆઉટને માનવ-લેબલ લગાવ્યા. અમે એ જ 100 પ્રિન્ટઆઉટ્સ પર LLM-જજ ચલાવ્યા અને માનવ-જજ કરારને માપ્યો - 85% કરાર, સ્વીકાર્ય. અમે દસ્તાવેજીકૃત કર્યું કે જ્યાં ન્યાયાધીશ વ્યવસ્થિત રીતે ખોટું થયું (લાંબા જવાબો અયોગ્ય રીતે સારા શોધવાનું વલણ) અને અમે ન્યાયાધીશ પર ભરોસો રાખ્યો ત્યારે જ તેના સ્કોર નિશ્ચિત કર્યા."

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

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

મૂલ્યાંકન સમૂહ: કાળજીપૂર્વક રચાયેલ

સારો ઇવેલ સેટ વાસ્તવિક વપરાશ અને મુશ્કેલ કેસોની વિવિધતાને રજૂ કરે છે. ફક્ત સરળ ઉદાહરણોથી ભરેલું ઇવેલ તમને ખોટા વિશ્વાસમાં છોડી દેશે. તેને eval ક્લસ્ટરમાં મૂકવાની ખાતરી કરો:

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

ઇવલ ક્લસ્ટર સમય સાથે વધે છે: તમે ઉત્પાદનમાં પકડો છો તે દરેક નવી ભૂલ આગામી મૂલ્યાંકન માટે એક પરીક્ષણ કેસ બની જાય છે.

એલાર્મ અને હસ્તક્ષેપ

એલાર્મ વિના મોનીટરીંગ અધૂરું રહે છે. દરેક મહત્વપૂર્ણ મેટ્રિક માટે થ્રેશોલ્ડ અને પ્રતિસાદ યોજના હોવી જોઈએ: "જો ઇનપુટ ડ્રિફ્ટ X કરતાં વધી જાય તો એન્જિનિયરને સૂચિત કરો", "જો ભૂલ દર Y કરતાં વધી જાય તો સ્વતઃ રોલ બેક કરો". એલાર્મને અર્થપૂર્ણ રાખો — ઘણા બધા ખોટા એલાર્મ ટીમને અસંવેદનશીલ બનાવે છે અને તેમને વાસ્તવિક એલાર્મ ચૂકી જાય છે.

ત્રણ નાના કેસો

કેસ 1 - પ્રારંભિક ચેતવણી. માંગ અનુમાન મોડેલની સાચી ચોકસાઈ અઠવાડિયાના અંતે જ સ્પષ્ટ થઈ ગઈ. ટીમ ઇનપુટ વિતરણ પર દેખરેખ રાખી રહી હતી અને મંગળવારે એક નવી પ્રોડક્ટ કેટેગરીમાં અચાનક વધારો જોયો - જે મોડલ ક્યારેય જોયો ન હતો. તેઓએ ચોકસાઈ ડ્રોપની રાહ જોયા વિના મોડેલને અપડેટ કર્યું. ઇનપુટ મોનીટરીંગ સાચવેલ દિવસો.

કેસ 2 - ચકાસાયેલ રેફરી. એક ટીમે LLM-સમીક્ષકના આધારે "અમારી ગુણવત્તા ઉત્તમ છે"ની જાણ કરી. જ્યારે ગ્રાહકની ફરિયાદોમાં વધારો થયો, ત્યારે માનવ દેખરેખની રજૂઆત કરવામાં આવી: રેફરીએ વિશ્વાસપૂર્વક પરંતુ ખોટા જવાબોને "સારા" તરીકે ગણ્યા. એકવાર રેફરીને માનવ ટૅગ્સ સાથે માપાંકિત કરવામાં આવ્યા પછી, સાચી ગુણવત્તા જાહેર થઈ અને તે ઘણી ઓછી હતી. પાઠ: રેફરીને ચકાસ્યા વિના તેના પર વિશ્વાસ ન કરો.

કેસ 3 - રીગ્રેશન પરીક્ષણ. ત્વરિત ફેરફારથી એક સમસ્યાનું નિરાકરણ થયું જ્યારે બીજાને શાંતિપૂર્વક તોડવામાં આવ્યું. પરંતુ ટીમે ભૂતકાળની ભૂલોને ઇવલ બકેટમાં રાખી; જ્યારે આ ક્લસ્ટર પર નવા ફેરફારનું પરીક્ષણ કરવામાં આવ્યું, ત્યારે તૂટેલા કેસ તરત જ પકડાઈ ગયા અને ફેરફારને ઠીક કરવામાં આવ્યો. પાઠ: દરેક નિશ્ચિત બગ કાયમી પરીક્ષણ કેસ બનવું જોઈએ.

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

આ ઉત્પાદન મોડલ માટે ટ્રેકિંગ પ્લાન તૈયાર કરો. ત્રણ સ્તરોને આવરી લો: 1) ઓપરેશનલ (લેટન્સી, એરર રેટ, વોલ્યુમ) 2) ઇનપુટ/ડેટા (ડિસ્ટ્રિબ્યુશન શિફ્ટ, ખૂટે છે, નવી કેટેગરી) 3) મોડલ/આઉટપુટ (પૂર્વાનુમાન વિતરણ, આત્મવિશ્વાસ, જો શક્ય હોય તો ચોકસાઈ) મોડલ: [વર્ણન]. વાસ્તવિક પરિણામ આવવામાં કેટલો સમય લાગે છે: [સમયગાળો]દરેક મેટ્રિક માટે થ્રેશોલ્ડ અને હસ્તક્ષેપની ભલામણ ઉમેરો.

આ LLM સિસ્ટમ માટે મૂલ્યાંકન (મૂલ્યાંકન) વ્યૂહરચના પ્રસ્તાવિત કરો. કાર્ય: [વર્ણન] સ્તરો નક્કી કરો:- દરેક આઉટપુટ પર કયા નિયમ-આધારિત તપાસો ચાલવા જોઈએ?- LLM-આર્બિટ્રેટરે કયા માપદંડોનું મૂલ્યાંકન કરવું જોઈએ અને તે કેવી રીતે માન્ય કરવું જોઈએ (માનવ એન્કર)?- કયા નમૂનામાં માનવ મૂલ્યાંકન કરવું જોઈએ અને સલામતી મૂલ્યાંકનના કેસોમાં માનવ મૂલ્યાંકન નક્કી કરવું જોઈએ.

આ LLM-રેફરી પ્રોમ્પ્ટ તપાસો:- શું મૂલ્યાંકન માપદંડ સ્પષ્ટ છે કે વ્યક્તિલક્ષી?- શું તે લંબાઈ/વિશ્વાસ પૂર્વગ્રહની સંભાવના ધરાવે છે?- હું માનવ ટૅગ્સ સાથે રેફરીને કેવી રીતે માપાંકિત કરી શકું? રેફરી પ્રોમ્પ્ટ: [પ્રોમ્પ્ટ]

આ મોનિટરિંગ એલાર્મ માટે પ્રતિભાવ રનબુક લખો. એલાર્મ: [દા.ત. ઇનપુટ ડ્રિફ્ટ થ્રેશોલ્ડ ઓળંગી]આમાં શામેલ હોવું જોઈએ: પ્રારંભિક નિયંત્રણ પગલાં, સંભવિત કારણો, રોલબેક માપદંડ, કોને જાણ કરવી.

બગાડ કારણ ટેબલ

વિકૃતિ

લક્ષણ

પ્રારંભિક તપાસનો માર્ગ

ડેટા ડ્રિફ્ટ

ઇનપુટ વિતરણ ફેરફારો

ઇનપુટ વિતરણ મોનીટરીંગ

ખ્યાલ શિફ્ટ

પ્રામાણિકતા ચુપચાપ પડી જાય છે

અનુમાન + વાસ્તવિક સરખામણી

અપસ્ટ્રીમ ભૂલ

ક્ષેત્રો ખાલી/ફોર્મેટમાં ફેરફાર થાય છે

સ્કીમા માન્યતા + ખૂટતો દર

મોડેલની અસંગતતા

આઉટપુટ વિતરણ પાળી

આઉટપુટ વિતરણ મોનીટરીંગ

સામાન્ય ભૂલો

• મોનીટરીંગ સ્થાપિત નથી. મોડેલ ચુપચાપ તૂટી જાય છે, કોઈ તેને જોતું નથી.
• માત્ર ઓપરેશનલ મેટ્રિક્સ ટ્રૅક કરો. સિસ્ટમ તૈયાર છે, પરંતુ આગાહીઓ ખોટી હોઈ શકે છે.
• રેફરીની ચકાસણી કર્યા વિના એલએલએમનો ઉપયોગ કરવો. તે ખોટો આત્મવિશ્વાસ આપે છે.
• સરળ ઉદાહરણો સાથે Eval. તે વાસ્તવિક મુશ્કેલી દર્શાવતું નથી.
• eval માં ભૂતકાળની ભૂલોનો સમાવેશ થતો નથી. એ જ ભૂલ ફરી પાછી આવે છે.
• મોટેથી એલાર્મ. ટીમ અસંવેદનશીલ બની જાય છે, વાસ્તવિક એલાર્મ ખૂટે છે.

સારાંશમાં

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

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

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

ચેકલિસ્ટ

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