Anthropic એ Claude Code ને માર્ગદર્શન આપતા સિસ્ટમ પ્રોમ્પ્ટમાંથી 80% ભાગ ઘટાડી નાખ્યો અને તેની કોડ લખવાની ક્ષમતામાં કોઈ ઘટાડો થયો હોવાનું જણાવ્યું નથી. આ પ્રયોગ દર્શાવે છે કે જેમ જેમ લાર્જ લેંગ્વેજ મોડલ્સ (LLMs) વધુ સક્ષમ બનતા જાય છે, તેમ તેમ ડેવલપર્સ મોડલ્સને સાચા માર્ગ પર રાખવા માટે ઉપયોગમાં લેવાતા બિનજરૂરી માળખાને (scaffolding) તેમની કામગીરીને નુકસાન પહોંચાડ્યા વિના ઘટાડી શકે છે.
પ્રોમ્પ્ટ શરૂઆતમાં શા માટે મહત્વનો હતો
જ્યારે Claude Code લોન્ચ થયું, ત્યારે તેના સિસ્ટમ પ્રોમ્પ્ટમાં ડઝનબંધ નિયમોની યાદી હતી. જ્યારે પણ કોઈ બગ (bug) દેખાય ત્યારે એન્જિનિયરો નવી લાઇન ઉમેરતા હતા પરંતુ જે નિયમો કામ કરી રહ્યા હતા તેને ભાગ્યે જ દૂર કરતા હતા. સમય જતાં પ્રોમ્પ્ટ એક જટિલ અને સ્થિર દસ્તાવેજ બની ગયો.
મોડલ ગેપ (model gap) ઓછો થઈ રહ્યો છે
તે વધારાના નિયમોએ એક “મોડલ ગેપ” છુપાવ્યો હતો – એટલે કે મોડલ શું કરી શકે છે અને એપ્લિકેશનની જરૂરિયાત શું છે તે વચ્ચેનો તફાવત. 2024 માં, ડેવલપર્સે મોડલને, ઉદાહરણ તરીકે, કોડમાં વધુ પડતા કોમેન્ટ્સ (over-commenting) લખતા રોકવા માટે કડક નિયમો સ્પષ્ટ કરવા પડતા હતા. આજે તે જ મોડલ “match the existing code style” જેવા સિંગલ ઇન્સ્ટ્રક્શન પરથી ઇચ્છિત શૈલી સમજી શકે છે. નિયમો હવે મદદ કરવાને બદલે ઘોંઘાટ (noise) બની ગયા છે.
કોન્ટેક્સ્ટ એન્જિનિયરિંગમાં શું બદલાઈ રહ્યું છે
Anthropic નું આ ઘટાડો ડેવલપર્સ પ્રોમ્પ્ટ કેવી રીતે તૈયાર કરે છે તેમાં આવતા વ્યાપક ફેરફારને પ્રતિબિંબિત કરે છે:
- વન-ટાઇમ ક્રિટિકલ ઇન્સ્ટ્રક્શન – નિયમ એકવાર જણાવો અને મોડલને તે યાદ રાખવા દો.
- Few-shot examples ને બદલે ટૂલ-ડ્રિવન પેરામીટર્સ – ટૂલ સ્કીમામાં ઇનપુટ અને આઉટપુટના પ્રકારોનું વર્ણન કરો અને મોડલને તે ભરવા દો.
- પ્રોગ્રેસિવ ડિસ્ક્લોઝર – વર્તમાન સ્ટેપ માટે જરૂરી કોન્ટેક્સ્ટ જ આપો, જો જરૂર પડે તો પછીથી વધુ માહિતી ઉમેરો.
- સ્ટેટિક માર્ગદર્શનને ટૂલ ડિસ્ક્રિપ્શનમાં ખસેડો – “use camelCase for variables” જેવી બાબતો ટૂલના સ્પેસિફિકેશનમાં હોવી જોઈએ, સિસ્ટમ પ્રોમ્પ્ટમાં નહીં.
- હાર્ડકોડેડ નિયમોને બદલે હ્યુરિસ્ટિક્સ (heuristics) નો ઉપયોગ કરો – નિયમ ક્યારે લાગુ કરવો તે મોડલ પર છોડી દો, તેને બિનશરતી લાગુ કરવાને બદલે.
આ પદ્ધતિઓ કામ કરે છે કારણ કે મોડલ પહેલેથી જ એવા ઘણા નિયમો જાણે છે જેને પહેલા સ્પષ્ટ રીતે કહેવાની જરૂર પડતી હતી.
વધારે પડતો ઘટાડો કરવાનો જોખમ
જે રીતે કાપ મૂકવાથી ફ્રન્ટિયર મોડલ્સને ફાયદો થાય છે, તે જ રીતે તે નાના મોડલ્સને નુકસાન પહોંચાડી શકે છે. Anthropic નોંધે છે કે Haiku જેવા મોડલ્સ હજુ પણ સાચા માર્ગ પર રહેવા માટે વધુ વિગતવાર પ્રોમ્પ્ટ્સ પર આધાર રાખે છે. ઓછી સક્ષમ મોડલમાંથી વધુ પડતું માર્ગદર્શન કાઢી નાખવાથી તે ભૂલો ફરીથી આવી શકે છે જેને મૂળ પ્રોમ્પ્ટ રોકવાનો પ્રયાસ કરતો હતો: જેમ કે અસંગત નામકરણ (inconsistent naming), વધુ પડતી કોમેન્ટ્સ અથવા મિસ થયેલા એજ કેસ (edge cases).
તમારા પોતાના પ્રોમ્પ્ટ્સનું ઓડિટ કેવી રીતે કરવું
જો તમે કોડ-જનરેશન પાઇપલાઇન ચલાવતા હોવ, તો પ્રોમ્પ્ટ ઓડિટ બિનજરૂરી બાબતોને બહાર લાવી શકે છે. એક વ્યવહારુ ચેકલિસ્ટ આ મુજબ છે:
- ઇન્સ્ટ્રક્શન ડેન્સિટીને ફરીથી સેટ કરો – તમે ખરેખર જે મોડલ ચલાવો છો તેને અનુરૂપ માર્ગદર્શન આપો.
- ડુપ્લીકેટ ઇન્સ્ટ્રક્શન દૂર કરો – જો કોઈ નિયમ સિસ્ટમ પ્રોમ્પ્ટ અને ટૂલ ડિસ્ક્રિપ્શન બંનેમાં હોય, તો તેને ફક્ત એક જ વાર રાખો.
- વર્ક કરેલા ઉદાહરણોને વધુ સારા સ્કીમામાં ફેરવો – ચોક્કસ ઉદાહરણોને બદલે એનુમેરેટેડ પેરામીટર પ્રકારો અથવા enums નો ઉપયોગ કરો.
- પરિસ્થિતિજન્ય વિગતોને એક્સટર્નલાઇઝ કરો – મોટા રેફરન્સ બ્લોક્સને અલગ ફાઇલોમાં ખસેડો જેને મોડલ જરૂરિયાત મુજબ મેળવી શકે.
- ગયેલા બિહેવિયર્સને આવરી લેતા નિયમો કાઢી નાખો – જો મોડલ હવે બિનજરૂરી કોમેન્ટ્સ ઉમેરતું નથી, તો “no-comment” નિયમ કાઢી નાખો.
માત્ર અંદાજ પર આધાર રાખશો નહીં. એક સરળ “3-ટેસ્ટ રૂલ” નો ઉપયોગ કરો: પાંચ વાસ્તવિક કોડિંગ કાર્યો ચલાવો, દરેક ડિલીશન પહેલા અને પછીના પરિણામોની તુલના કરો, અને કોઈપણ ઘટાડા (regressions) નો નોંધ લો.
- બેઝલાઇન – સંપૂર્ણ પ્રોમ્પ્ટ સાથે કામગીરી માપો.
- ડિલીટ – કોઈ સંભવિત લાઇન અથવા બ્લોક દૂર કરો.
- રી-રન – તે જ પાંચ કાર્યો ફરીથી ચલાવો.
જો આઉટપુટ બદલાય છે, તો તમે એવી લાઇન શોધી લીધી છે જે હજુ પણ મહત્વ ધરાવે છે. જો ન બદલાય, તો તે લાઇન સુરક્ષિત રીતે કાઢી શકાય છે.
ડેવલપર્સે હવે આગળ શું જોવું જોઈએ
હાલ માટે, મુખ્ય વાત સ્પષ્ટ છે: સિસ્ટમ પ્રોમ્પ્ટ એ એક જીવંત દસ્તાવેજ છે. દરેક લાઇનને તેની અવધિ (shelf life) હોય તેમ ગણો, નિયમિત ઓડિટ કરો, અને મોડલની વધતી જતી ક્ષમતાને મુખ્ય કામ કરવા દો.
Source: dev.to/ialijr/your-system-prompt-has-a-shelf-life-maintaining-prompts-as-models-improve-cd9