ઇવેલ-ડ્રિવન એજન્ટ ડેવલપમેન્ટ: મેં કેવી રીતે 'વાઇબ્સ' (vibes) પર પ્રોમ્પ્ટ્સ ટ્યુન કરવાનું બંધ કર્યું

મેં એક પ્રોમ્પ્ટ બદલ્યો. પછીનું રન (run) વધુ સારું દેખાયું. શું તે ફેરફારથી મદદ મળી, કે હું નસીબદાર હતો?

લાંબા સમય સુધી, મારો જવાબ હતો "મને લાગે છે તેમ છે." હું એક કમાન્ડમાં ફેરફાર કરતો, પાઇપલાઇન ચલાવતો, તેને સફળ થતો જોતો અને પછી તેને શિપ (ship) કરી દેતો. આ 'વાઇબ્સ-આધારિત' (vibes-based) એન્જિનિયરિંગ છે. એજન્ટ બનાવનાર લગભગ દરેક વ્યક્તિ આવું જ કરે છે કારણ કે તેના બદલે બીજો વિકલ્પ અઘરો લાગે છે.

પરંતુ કોડિંગ એજન્ટ્સ નોન-ડિટરમિનિસ્ટિક (non-deterministic) હોય છે. તમે એક જ કાર્ય બે વાર કરી શકો છો અને બે અલગ પરિણામો મેળવી શકો છો. એક જ સારું રન તમને કંઈ જ કહેતું નથી. તમે એ જાણી શકતા નથી કે તમારો ફેરફાર કામ કરી ગયો કે માત્ર નસીબ સાથ આપી ગયું.

મેં મશીન લર્નિંગના શિસ્તનો ઉપયોગ કરીને આ સમસ્યાનો ઉકેલ લાવ્યો. મેં મારી સમગ્ર સિસ્ટમને આવરી લેવા માટે એક ઇવેલ્યુએશન ફ્રેમવર્ક (evaluation framework) બનાવ્યું.

અહીં ફ્રેમવર્ક કેવી રીતે કામ કરે છે:

• ટાર્ગેટ (Target): એક ફ્રોઝન કોડબેઝ (frozen codebase). સ્કોર્સની તુલના કરી શકાય તે માટે આ સમાન રહે છે. • ટાસ્ક (Task): પ્રોમ્પ્ટ અને ઓરેકલ (oracle) સાથેની એક ચોક્કસ બેન્ચમાર્ક આઇટમ. • ઓરેકલ (Oracle): એક ડિટરમિનિસ્ટિક ચેક. આ એવી શેલ કમાન્ડ્સ છે જે પાસ થવી જ જોઈએ. • વેરિઅન્ટ (Variant): તમે જે ચોક્કસ ફેરફારનું પરીક્ષણ કરી રહ્યા છો, જેમ કે નવો પ્લાનર. • ટ્રાયલ (Trial): એક સિંગલ રન. રેન્ડમનેસ (randomness) ને ધ્યાનમાં લેવા માટે હું દરેક કાર્ય અનેક વાર ચલાવું છું.

હું વિવિધ નિષ્ફળતાઓ પકડવા માટે બે પ્રકારના સ્કોરિંગનો ઉપયોગ કરું છું:

  • કોડ ગ્રેડર્સ (Code Graders - Deterministic): આ ટેસ્ટ પાસ રેટ, ખર્ચ, સમય અને ફાઇલ ફેરફારો તપાસે છે.
  • LLM જજ (LLM Judge - Probabilistic): એક અલગ, ફિક્સ્ડ મોડલ સ્પેક ક્વોલિટી અને ઇમ્પ્લીમેન્ટેશન ફિડેલિટી (implementation fidelity) ને સ્કોર આપે છે.

કોડ ગ્રેડર્સ તમને જણાવે છે કે કોડ ચાલે છે કે નહીં. જજ તમને જણાવે છે કે કોડ સારો છે કે નહીં. તમારે બંનેની જરૂર છે.

મેં સરેરાશ (averages) નો ઉપયોગ કરવાનું પણ બંધ કરી દીધું છે. મીન (means) એજન્ટ્સ વિશે ખોટું બોલે છે. જો કોઈ કાર્ય 3 માંથી 2 વખત સફળ થાય, તો તે ઠીક લાગે છે. પરંતુ તે વિશ્વસનીય નથી. તેના બદલે, હું બે મેટ્રિક્સનો ઉપયોગ કરું છું:

  • pass@k: શું એજન્ટ ઓછામાં ઓછી એક વાર સફળ થયો? (ક્ષમતા - Capability)
  • pass^k: શું એજન્ટ દરેક વખતે સફળ થયો? (વિશ્વસનીયતા - Reliability)

pass^k માં વધારો એ સાચી જીત છે. તેનો અર્થ એ છે કે તમે એજન્ટને માત્ર નસીબદાર નહીં, પણ સુસંગત (consistent) બનાવ્યો છે.

સિસ્ટમને સચોટ રાખવા માટે, હું ઊંડી સમજણની જરૂર હોય તેવા અઘરા કાર્યો ઉમેરું છું. જ્યારે કોઈ એજન્ટ વાસ્તવિક બગ (bug) પર નિષ્ફળ જાય છે, ત્યારે હું તે નિષ્ફળતાને કાયમી કાર્યમાં બદલી નાખું છું. આ એક ક્લોઝ્ડ લૂપ (closed loop) બનાવે છે. જેમ જેમ એજન્ટ વધુ સારો બનતો જાય તેમ બેન્ચમાર્ક વધુ અઘરો બનતો જાય છે.

આ ઇન્ફ્રાસ્ટ્રક્ચર બનાવવામાં ઘણું કામ લાગે છે, પરંતુ તે મેં બનાવેલી સૌથી વધુ અસરકારક (highest leverage) વસ્તુ છે. તેણે "મને લાગે છે કે આ વધુ સારું છે" ને બદલે "આ ઓછા ખર્ચે 20% વધુ વિશ્વસનીય છે" માં બદલી નાખ્યું.

કોડિંગ એજન્ટ્સનું ડેમો આપવો સરળ છે પરંતુ તેમના પર વિશ્વાસ કરવો મુશ્કેલ છે. જો તમે ડેમોથી આગળ વધવા માંગતા હોવ, તો તમારે માપન (measure) કરવાનું નક્કી કરવું પડશે.

સ્ત્રોત: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

વૈકલ્પિક લર્નિંગ કોમ્યુનિટી: https://t.me/GyaanSetuAi