ટેસ્ટ શા માટે મહત્વપૂર્ણ છે

AI-આધારિત કોડ આસિસ્ટન્ટ્સ ઘણીવાર ટીમોને રિપોઝિટરીમાં "rules" ફાઇલ મૂકવા દે છે અને દરેક વિનંતી (request) પર મોડેલ તેના નિર્દેશોનું પાલન કરે તેવી અપેક્ષા રાખે છે. વ્યવહારમાં, મોડેલ કદાચ તે ફાઇલ ક્યારેય જોઈ શકતું નથી, અથવા તે તેને જોઈ શકે છે પરંતુ તેની સામગ્રીને અવગણી શકે છે. Claude Code સાથેના તાજેતરના પ્રયોગે આ બંને સમસ્યાઓ દર્શાવી છે. ટૂલે 72 KB ની AGENTS.md ફાઇલને ચુપચાપ સ્કીપ કરી દીધી; જ્યારે તે જ ફાઇલનું નામ બદલીને CLAUDE.md કરવામાં આવ્યું, ત્યારે આસિસ્ટન્ટે તેને લોડ કરી અને દરેક વિનંતી માટે ટોકન કાઉન્ટ વધારી દીધું. તે વધારાનું ટોકન બજેટ લેટન્સી (latency), ખર્ચ વધારે છે અને વિનંતીને મોડેલની મર્યાદાથી બહાર ધકેલી શકે છે.

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

પૂછવા માટેના ત્રણ પ્રશ્નો

  1. Configured (કોન્ફિગર કરેલ) – શું ફાઇલ ત્યાં મૂકવામાં આવી છે જ્યાં આસિસ્ટન્ટ તેને શોધે છે? વિવિધ ટૂલ્સ પાથ અથવા ફાઇલના નામની પદ્ધતિઓ (conventions) હાર્ડ-કોડ કરે છે; જો તેમાં તફાવત હોય, તો તેનો અર્થ એ છે કે ફાઇલ પ્રોમ્પ્ટ પાઇપલાઇનમાં ક્યારેય પ્રવેશતી નથી.
  2. Loaded (લોડ કરેલ) – શું આસિસ્ટન્ટ એનો કોઈ પુરાવો આપે છે કે તેને ફાઇલ મળી છે? ડિસ્ક પર ફાઇલની ઓળખની પુષ્ટિ કરવા માટે 'hash' કરી શકે છે, પરંતુ માત્ર ડિલિવરી ટ્રેસ (દા.ત., લોગ લાઇન અથવા ટોકન કાઉન્ટ) જ સાબિત કરે છે કે મોડેલે ખરેખર તેને જોયું છે.
  3. Useful (ઉપયોગી) – શું ફાઇલની હાજરીથી કાર્યનું પરિણામ સુધરે છે? જો લોડ કરેલી ફાઇલ ટોકન્સ વધારે છે પરંતુ પરિણામમાં કોઈ ફેરફાર કરતી નથી, તો તે નુકસાન સમાન છે.

ટેસ્ટ ચલાવવી

આ પ્રક્રિયા જાણીજોઈને લઘુતમ રાખવામાં આવી છે જેથી તેને કોઈપણ પ્લેટફોર્મ પર ફરીથી કરી શકાય.

  1. એક દેખીતી નિયમ બનાવો – એક સરળ, અવલોકન કરી શકાય તેવું સૂચન લખો. ઉદાહરણ તરીકે: “એડિટ કરતા પહેલા બરાબર બે ફાઇલોની યાદી બનાવો.” આ નિયમની અસર આસિસ્ટન્ટના પ્રતિસાદમાં તપાસી શકાય છે.

  2. ટૂલનું વર્ઝન અને મોડેલ તપાસો – એક નવું સેશન ખોલો, વર્ઝન સ્ટ્રિંગ અને મોડેલ આઈડેન્ટિફાયર નોંધી લો. વિવિધ વર્ઝન દ્વારા ઓળખવામાં આવતા ફાઇલના નામો બદલાઈ શકે છે.

  3. બે રન (runs) ચલાવો Run A: એવું ફાઇલ નામ વાપરો જેને ટૂલ ઓળખતું નથી (દા.ત., AGENTS.md). Run B: ટૂલનું નેટિવ (native) ફાઇલ નામ વાપરો (દા.ત., CLAUDE.md).

    નોંધો:

    • ફાઇલનો સોર્સ hash (તે સાબિત કરવા માટે કે ડિસ્ક પરની સામગ્રી બદલાઈ નથી).
    • વપરાયેલ ચોક્કસ પાથ (path).
    • આસિસ્ટન્ટે ફાઇલ લોડ કરવા વિશે જે પણ પુરાવા લોગ કર્યા હોય તે (ટોકન કાઉન્ટમાં વધારો, સ્પષ્ટ “loaded X.md” સંદેશ વગેરે).
    • દરેક વિનંતી માટે ટોકન કાઉન્ટ.
    • કાર્યનું પરિણામ (શું આસિસ્ટન્ટે બરાબર બે ફાઇલોની યાદી બનાવી?).

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

ડેટા શું દર્શાવે છે

Claude Code ના કિસ્સાએ કોન્ફિગરેશન અને લોડિંગ વચ્ચેનો મોટો તફાવત દર્શાવ્યો છે. 72 KB ની ફાઇલ અસ્તિત્વમાં હતી, તેનો hash સાચો હતો અને તે રિપોઝિટરી સાથે સિંક થયેલ હતી, તેમ છતાં આસિસ્ટન્ટે તેનો ક્યારેય સંદર્ભ આપ્યો નહોતો. ફાઇલનું નામ બદલીને નેટિવ CLAUDE.md કરવાથી લોડિંગ શરૂ થયું, પરંતુ તેનાથી નોંધપાત્ર ટોકન ઓવરહેડ પણ ઉમેરાયો. દરેક વધારાનો ટોકન કમ્પ્યુટ સાયકલનો વપરાશ કરે છે અને વિનંતીને રેટ લિમિટ (rate limits) થી બહાર ધકેલી શકે છે.

આ ત્રણ-પગલાંની ટેસ્ટ આવા છુપા ખર્ચાઓને પ્રોડક્શન બ્લોકર બનતા પહેલા બહાર લાવે છે. ટોકન ડેલ્ટા (token delta) ને કેપ્ચર કરીને, ટીમો નક્કી કરી શકે છે કે નિયમનો ફાયદો તેની કિંમત કરતા વધારે છે કે નહીં.

મુખ્ય વાત (Takeaway)

માત્ર રિપોઝિટરીમાં હોવાને કારણે નિયમની ફાઇલ કામ કરી રહી છે તેમ ક્યારેય માની ન લો. તે ધારણાને માપી શકાય તેવા પુરાવામાં બદલવા માટે ત્રણ-પગલાંની ટેસ્ટ—કોન્ફિગર, લોડ, ઉપયોગિતા સાબિત કરો—નો ઉપયોગ કરો. જ્યારે પુરાવા દર્શાવે કે ફાઇલ માત્ર એક 'ટોકન સિંક' (token sink) છે, ત્યારે લોજિકને પ્રોમ્પ્ટમાંથી બહાર કાઢીને ડિટરમિનિસ્ટિક ગેટ (deterministic gate) માં ખસેડો. તેનું પરિણામ વધુ સુસંગત, ઝડપી અને વધુ અનુમાનિત AI કોડિંગ વર્કફ્લો હશે.