તમે એક એવું ઇન્ટરનલ ટૂલ બનાવ્યું છે જે એક ટીમને મોડેલની API ને ક્યારેય કોલ કર્યા વગર LLM-સંચાલિત ફીચર પર 28 યુનિટ ટેસ્ટ ચલાવવાની મંજૂરી આપે છે. તમે તેને મોડેલને એક ફેકેબલ ઇન્ટરફેસ (fakeable interface) માં લપેટીને અને ત્રણ સ્તરો - ડિટરમિનિસ્ટિક (deterministic), હ્યુરિસ્ટિક (heuristic) અને LLM-આધારિત ઇવેલ્યુએશન ઉમેરીને કર્યું છે.

જ્યારે LLM ગદ્ય (prose) જનરેટ કરે છે ત્યારે સ્ટાન્ડર્ડ એસર્શન્સ (assertions) તૂટી જાય છે. એક જ પ્રોમ્પ્ટ દરેક રન પર અલગ વાક્ય આપી શકે છે, તેથી assertEqual(output, expected) મોડેલ સાચું વર્તન કરતું હોય તો પણ નિષ્ફળતા (failure) દર્શાવે છે. મોટાભાગના એન્જિનિયરિંગ ગ્રુપ્સ કાં તો વેરિફિકેશન વગર ફીચર શિપ કરે છે અથવા મોડેલને પોતે ટેસ્ટ કરવાનો પ્રયાસ કરે છે, જે સતત બદલાતા લક્ષ્યને સ્થિર લાઇબ્રેરી તરીકે માને છે.

આ સમસ્યા શા માટે મહત્વની છે

LLMs હવે ગ્રાહક-સંબંધિત વર્કફ્લોમાં — ઇમેઇલ આઉટરીચ, સપોર્ટ રિપ્લાય, કન્ટેન્ટ જનરેશન — સ્થાન ધરાવે છે. એક જ ખોટી રીતે જનરેટ થયેલ તથ્ય (hallucinated fact) અથવા લીક થયેલ આઇડેન્ટિફાયર બ્રાન્ડની પ્રતિષ્ઠાને નુકસાન પહોંચાડી શકે છે, ખાનગી ડેટાને ખુલ્લો કરી શકે છે અથવા કમ્પ્લાયન્સ ઉલ્લંઘનનું કારણ બની શકે છે. વિશ્વસનીય ટેસ્ટ સ્ટ્રેટેજી વગર, ટીમો અસ્થિર નિષ્ફળતાઓ (flaky failures) પાછળ સમય બગાડે છે અથવા એવા બગ્સ શિપ કરે છે જે માત્ર પ્રોડક્શનમાં જ સામે આવે છે.

અભિગમ: મોડેલની જવાબદારી ઘટાડો

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

તેને શક્ય બનાવવા માટે, LLM એક પ્રોવાઈડર ઇન્ટરફેસ પાછળ રહે છે, જે ટેસ્ટમાં ફેક (fake) વર્ઝનનો ઉપયોગ કરવાની મંજૂરી આપે છે. પ્રોડક્શનમાં ઇમ્પ્લીમેન્ટેશન એક્સટર્નલ API ને કોલ કરે છે; ટેસ્ટ સૂટમાં એક લાઇટવેઇટ ફેક (fake) કેનડ (canned) રિસ્પોન્સ રિટર્ન કરે છે. કારણ કે બાકીનો કોડ ફક્ત ઇન્ટરફેસ સાથે જ ઇન્ટરેક્ટ કરે છે, આખું વર્કફ્લો એવા યુનિટ ટેસ્ટ દ્વારા ચલાવી શકાય છે જે ક્યારેય નેટવર્કને સ્પર્શતા નથી. પરિણામ એક અનુમાનિત (predictable) કોર છે જેને 28 ટેસ્ટ વેરિફાય કરે છે.

એક પ્રમાણિક ઇવેલ્યુએશન હાર્નેસ

મર્યાદિત સ્કોપ હોવા છતાં, મોડેલનું આઉટપુટ નોન-ડિટરમિનિસ્ટિક (nondeterministic) રહે છે. તેથી લેખકે ત્રણ-સ્તરીય ઇવેલ્યુએશન હાર્નેસ બનાવ્યો છે, જેમાં દરેક સ્તર જોખમના અલગ પ્રકારને હેન્ડલ કરે છે.

  • લેયર 1 – ડિટરમિનિસ્ટિક ચેક્સ સરળ રેગ્યુલર-એક્સપ્રેશન નિયમો ખોટી બિલ્ડિંગ ID અથવા પ્રતિબંધિત ટોકન્સ જેવી ચોક્કસ ભૂલો પકડી લે છે. આ ચેક્સ ઝડપી છે અને બાઈનરી પાસ/ફેલ (pass/fail) પરિણામ આપે છે.

  • લેયર 2 – હ્યુરિસ્ટિક ચેક્સ સ્ક્રિપ્ટ્સ ખોટી રીતે જનરેટ થયેલા (hallucinated) નંબરો અથવા તારીખો શોધે છે, જે સ્પષ્ટ તથ્યપૂર્ણ બનાવટને ફ્લેગ કરે છે. તેઓ એવા ખોટા દાવાઓને ચૂકી જાય છે જેમાં ન્યુમેરિક ક્યુઝ (numeric cues) હોતા નથી, અને લેખક ખુલ્લેઆમ આ મર્યાદા સ્વીકારે છે.

  • લેયર 3 – LLM જજ એક સેકન્ડરી મોડેલ ટોન અને પ્રોફેશનલિઝમનું રેટિંગ કરે છે. કારણ કે આ સ્ટેપ અન્ય પ્રોબેબિલિસ્ટિક સિસ્ટમ પર આધારિત છે, તેનો ઉપયોગ ફક્ત વિષયલક્ષી (subjective) પાસાઓ માટે કરવામાં આવે છે જ્યાં ડિટરમિનિસ્ટિક નિયમો અશક્ય હોય.

હાર્નેસની ચાવી ઇવેલ્યુએશન માટે વપરાતો ડેટાસેટ છે. લેખકે જાણીતા નિષ્ફળતાના પેટર્ન—ચોક્કસ ટ્રેપ્સ અને ડોમેન નોલેજ—ને એન્કોડ કર્યા છે જેથી હાર્નેસ બરાબર એ જ ભૂલોનું પરીક્ષણ કરે છે જે પ્રેક્ટિસમાં જોવા મળી છે. તે કોઈ જાદુઈ “catch-all” નથી પરંતુ એક લક્ષિત સેફ્ટી નેટ છે.

ટીમો માટે આનો અર્થ શું છે

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

કાઉન્ટર-પોઈન્ટ: તમે હજુ પણ મોડેલને પોતે યુનિટ-ટેસ્ટ કરી શકતા નથી

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

મુખ્ય વાત (Takeaway)

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