એક સંશોધન ટીમે એ નક્કી કરવા માટે એક રાઉટર બનાવ્યું કે શું સસ્તું લેંગ્વેજ મોડલ કોડિંગ વિનંતીને હેન્ડલ કરી શકે છે, જેનો હેતુ ઇન્ફરન્સ ખર્ચ ઘટાડવાનો હતો, પરંતુ રાઉટર "never-escalate" બેઝલાઇનને હરાવી શક્યું નહીં. આ નિષ્ફળતા દર્શાવે છે કે શા માટે ચોકસાઈ-કેન્દ્રિત મેટ્રિક્સ કેસ્કેડ્સને ગેરમાર્ગે દોરે છે અને એવા સિગ્નલો તરફ નિર્દેશ કરે છે જે ખરેખર મુશ્કેલીને પકડી શકે છે.
રાઉટર શા માટે મહત્વનું હતું
મોડલ કેસ્કેડ્સ દરેક વિનંતીને તે સાચી રીતે જવાબ આપી શકે તેવા સૌથી નાના મોડલને મોકલે છે. જો રાઉટર સાદી પ્રોમ્પ્ટને સસ્તા મોડલને મોકલે છે, તો સિસ્ટમ મોટા મોડલ માટે જરૂરી મોંઘા કમ્પ્યુટિંગને ટાળી દે છે. ટીમે 539 વાસ્તવિક કોડિંગ કાર્યો—428 સરળ અને 111 અઘરા—પર રાઉટરને તાલીમ આપી હતી, એવી અપેક્ષા સાથે કે તે શીખી લેશે કે ક્યારે સસ્તું મોડલ પૂરતું રહેશે.
જે આંકડાઓ નિષ્ફળ રહ્યા
- Held-out AUC (area under the ROC curve): 0.594
- 5-fold cross-validation range: 0.55 – 0.57
- શ્રેષ્ઠ થ્રેશોલ્ડ: "never-escalate" ની પોલિસી સાથે મેળ ખાય છે
Held-out AUC 0.594 હતો અને cross-validation 0.55 થી 0.57 ની વચ્ચે હતો, જેનો અર્થ છે કે ક્લાસિફાયર સરળ અને અઘરા કિસ્સાઓને માંડ અલગ કરી શકે છે. જ્યારે શ્રેષ્ઠ થ્રેશોલ્ડ એવી પોલિસી બનાવે છે જે ક્યારેય મોંઘા મોડલનો ઉપયોગ કરતી નથી, ત્યારે રાઉટર કોઈ મૂલ્ય ઉમેરતું નથી. તે નિર્ણય લેનારને બદલે એક સ્થિર અનુમાન લગાવનાર (constant predictor) તરીકે વર્તે છે.
પ્રયોગોમાં શું ટેસ્ટ કરવામાં આવ્યું હતું
સંશોધકોએ ત્રણ ફીચર સેટ્સની સરખામણી કરી:
| ફીચર સેટ | AUC |
|---|---|
| 11 સરળ સરફેસ ફીચર્સ (દા.ત., ટોકન કાઉન્ટ, કીવર્ડની હાજરી) | 0.610 |
| 1024-પરિમાણીય પ્રોમ્પ્ટ એમ્બેડિંગ (semantic vector) | 0.552 |
| બંનેનું મિશ્રણ | 0.609 |
આશ્ચર્યજનક રીતે, હળવા (lightweight) સરફેસ ફીચર્સ હાઈ-ડાયમેન્શનલ સેમેન્ટિક એમ્બેડિંગ કરતા વધુ સારું પ્રદર્શન કરતા હતા. એમ્બેડિંગ પ્રોમ્પ્ટના વિષયને પકડી લેતું હતું પરંતુ તેની આંતરિક મુશ્કેલીને નહીં. સસ્તા મોડલના ડ્રાફ્ટને રાઉટરને આપવાથી AUC વધીને 0.640 થઈ ગયું, જે સૂચવે છે કે જનરેશન દરમિયાન દેખાતા સિગ્નલો માત્ર પ્રોમ્પ્ટમાં રહેલા સિગ્નલો કરતા વધુ માહિતીપ્રદ છે.
બે મૂળભૂત ખામીઓ
1. ચોકસાઈ એ ખોટું માપદંડ છે
રાઉટરે માત્ર સાચા હોવાની આગાહી કરવાને બદલે, એક સાદી (naïve) પોલિસીની સરખામણીમાં ખર્ચ-ચોકસાઈના સંતુલનને (cost-accuracy trade-off) સુધારવું જોઈએ. જો તે "never-escalate" કરતા વધુ સારું પ્રદર્શન ન કરી શકે, તો તે કાચી ચોકસાઈ ગમે તે હોય, કોઈ ખર્ચનો લાભ આપતું નથી. AUC જેવા પરંપરાગત મેટ્રિક્સ કેસ્કેડના આર્થિક પાસાને અવગણે છે.
2. "always escalate" એ સીમા નથી
પ્રયોગમાં એવું માની લેવામાં આવ્યું હતું કે મોંઘું મોડલ અચૂક છે, અને "હંમેશા મોટા મોડલનો ઉપયોગ કરો" ને ઉપલી મર્યાદા તરીકે ગણવામાં આવ્યું હતું. વાસ્તવમાં, મોટું મોડલ ક્યારેક એવા જવાબો બગાડી નાખતું હતું જે સસ્તું મોડલ સાચા રીતે આપી શકતું હતું. એક સંપૂર્ણ રાઉટર જે જાણે છે કે ક્યારે સસ્તા મોડલ સાથે રહેવું, તે પસંદ કરેલા ખર્ચ મેટ્રિકમાં "always escalate" બેઝલાઇનને લગભગ 4.2 પોઈન્ટ્સ થી હરાવી શકે છે. આ તફાવત દર્શાવે છે કે મોંઘા મોડલની કામગીરીની સીમા ધારણા કરતા ઓછી છે.
વધુ સારા રાઉટિંગ સિગ્નલ્સ ડિઝાઇન કરવા
તારણો ત્રણ વ્યવહારુ દિશાઓ સૂચવે છે:
- જનરેશન-ટાઇમ સંકેતોનો સમાવેશ કરો. સસ્તા મોડલના મધ્યવર્તી આઉટપુટ (તેના ડ્રાફ્ટ) ને રાઉટરને આપવાથી એવી મુશ્કેલી પકડાય છે જે માત્ર પ્રોમ્પ્ટ દ્વારા છુપાયેલી રહે છે.
- કાર્ય-વિશિષ્ટ (task-specific) સરફેસ ફીચર્સને પ્રાધાન્ય આપો. લંબાઈ, ચોક્કસ ઓપરેટર્સની હાજરી અથવા કોડ-સ્ટાઇલ માર્કર્સ જેવા સરળ મેટ્રિક્સ સામાન્ય સેમેન્ટિક એમ્બેડિંગ કરતા વધુ અનુમાનિત હોઈ શકે છે.
- ખર્ચ-જાગૃત (cost-aware) મેટ્રિક્સ સાથે સફળતા માપો. શુદ્ધ ચોકસાઈ અથવા AUC ને બદલે, લક્ષ્ય ગુણવત્તા સ્તર જાળવી રાખીને કેટલા મોંઘા કોલ્સ ટાળવામાં આવ્યા છે તેનું મૂલ્યાંકન કરો.
સારાંશ: જે રાઉટર માત્ર ચોકસાઈ માટે ઓપ્ટિમાઇઝ કરે છે તે ખર્ચમાં બચતની ખાતરી આપી શકતું નથી; અસરકારક રાઉટિંગ માટે જનરેશન-ટાઇમ પુરાવા અને ખર્ચ-જાગૃત મૂલ્યાંકનની જરૂર છે.