લાર્જ લેંગ્વેજ મોડલ્સ (LLMs) વિશે કોઈપણ ટેકનિકલ ચર્ચામાં પાંચ મિનિટ વિતાવો અને તમે એ જ સવાલ સાંભળશો: કયું મોડલ શ્રેષ્ઠ છે? ટીમો બેન્ચમાર્ક લીડરબોર્ડ્સ, પેરામીટર કાઉન્ટ્સ અને કોન્ટેક્સ્ટ વિન્ડો સાઈઝ વિશે એવી રીતે ચિંતા કરે છે જાણે કે બેઝ મોડલની પસંદગી એ એકમાત્ર નિર્ણય હોય જે નક્કી કરે છે કે AI પ્રોડક્ટ સફળ થશે કે નિષ્ફળ. તેવું નથી. વાસ્તવિક પ્રોડક્શન સિસ્ટમ્સમાં, મોડલ કરતાં તેની આસપાસનું હાર્નેસ (harness) વધુ મહત્વનું છે.
હાર્નેસ વગરનું મોડલ માત્ર એક ટેક્સ્ટ જનરેટર છે. હાર્નેસ તે જનરેટરને કંઈક એવું બનાવે છે જે વપરાશકર્તાઓ અથવા મહત્વપૂર્ણ બિઝનેસ લોજિક સામે મૂકવા માટે વિશ્વસનીય, અવલોકનક્ષમ (observable) અને સુરક્ષિત હોય.
હાર્નેસ ખરેખર શું છે
હાર્નેસ એ તમામ બાબતોનો સમૂહ છે જે રૉ મોડલ વેટ્સ (raw model weights) અને તમારા અંતિમ વપરાશકર્તાને મળતા મૂલ્ય વચ્ચે હોય છે. તેમાં પ્રોમ્પ્ટ મેનેજમેન્ટ, રિટ્રીવલ પાઈપલાઈન્સ, આઉટપુટ વેલિડેશન, ટૂલ ઓર્કેસ્ટ્રેશન, ઇવેલ્યુએશન સૂટ્સ, લોગિંગ, ફોલબેક લોજિક, કોસ્ટ કંટ્રોલ્સ અને ફીડબેક મિકેનિઝમ્સનો સમાવેશ થાય છે. મોડલને એક એન્જિન તરીકે અને હાર્નેસને ચેસીસ, બ્રેક્સ, સ્ટીયરિંગ અને ડેશબોર્ડ તરીકે વિચારો. નબળા માળખામાં બેઠેલું શક્તિશાળી એન્જિન વળાંક પર આવતાની સાથે જ અકસ્માતનો ભોગ બની જશે.
ઘણી ટીમો ઇન્ટિગ્રેશનને માત્ર એક સિંગલ API કોલ તરીકે જુએ છે. તેઓ યુઝર સ્ટ્રિંગને સીધી chat.completions.create માં પાસ કરે છે, પરિણામને સ્ક્રીન પર બતાવે છે, અને તેને પ્રોડક્ટ કહે છે. તે ડેમો માટે કામ કરી શકે છે. પરંતુ જે ક્ષણે તમારે અસ્પષ્ટતા, એડવર્સરીયલ ઇનપુટ (adversarial input), મલ્ટી-સ્ટેપ રીઝનિંગ અથવા બાહ્ય સિસ્ટમ સાથે જોડાણ સંભાળવાની જરૂર પડે છે, ત્યારે તે નિષ્ફળ જાય છે. હાર્નેસ એ જગ્યા છે જ્યાં એન્જિનિયરિંગ શિસ્ત (engineering discipline) રહેલી છે. તે એ જગ્યા છે જ્યાં તમે ભૂલોને પકડો છો, હેલ્યુસિનેશન (hallucinations) માંથી રિકવર કરો છો, અને ખાતરી કરો છો કે એક મદદરૂપ AI ભૂલથી ડેટાબેઝ રેકોર્ડ ડિલીટ ન કરી દે કારણ કે તેણે સ્કીમા (schema) ખોટી રીતે વાંચ્યું હોય.
બેન્ચમાર્ક અધૂરી માહિતી આપીને છેતરે છે
જાહેર બેન્ચમાર્ક વ્યાપક જ્ઞાનને માપે છે, તમારી ચોક્કસ સમસ્યાને નહીં. એક મોડલ મેડિકલ લાયસન્સિંગ પ્રશ્નો પર નવ્વાણુંમી સેન્ટાઇલ (ninetieth percentile) સ્કોર કરી શકે છે અને તેમ છતાં તમારા આંતરિક ટિકિટ-રૂટિંગ વર્કફ્લોમાં નિષ્ફળ જઈ શકે છે કારણ કે તેની ક્યારેય તમારી ટૂંકાક્ષરો (abbreviations), તમારા એજ કેસીસ (edge cases), અથવા તમારા એવા વપરાશકર્તાઓ સામે ટેસ્ટ કરવામાં આવી નહોતી જે એક જ વાક્યમાં ત્રણ ભાષાઓ લખતા હોય.
હાર્નેસ તે અંતરને પૂરે છે. યોગ્ય ઇવેલ્યુએશન હાર્નેસ તમારા વાસ્તવિક પ્રોડક્શન પ્રોમ્પ્ટ્સને તમારા વાસ્તવિક અપેક્ષિત આઉટપુટ્સ સામે ચલાવે છે, કોઈ બીજાના પ્રમાણિત ટેસ્ટ સામે નહીં. જ્યારે તમે એક મોડલ પ્રોવાઈડરથી બીજા પર સ્વિચ કરો છો ત્યારે તે રિગ્રેશન (regressions) ને ટ્રેક કરે છે. તે એ ૨ ટકા ઇનપુટ્સને પણ શોધી કાઢે છે જે મોટી ગેરસમજ ઊભી કરે છે. આ વગર, તમે અંધારામાં વિમાન ઉડાવી રહ્યા છો. આની સાથે, તમે નાના અને સસ્તા મોડલનો ઉપયોગ કરીને મોટા મોડલ કરતા વધુ સારું પ્રદર્શન કરી શકો છો કારણ કે તમે નિષ્ફળતાના પ્રકારોને ઓળખી લીધા છે અને તેને કોન્ટેક્સ્ટ ઇન્જેક્શન અથવા પોસ્ટ-પ્રોસેસિંગ રૂલ્સ દ્વારા સુધારી લીધા છે.
સુરક્ષા હાર્નેસમાં રહેલી છે, વેટ્સમાં નહીં
મર્યાદાઓ વગરની ક્ષમતાઓ જોખમી છે. વિશ્વનું સૌથી સ્માર્ટ મોડલ પણ પ્રોડક્શન APIs, ગ્રાહક ડેટા અથવા એક્ઝિક્યુટેબલ કોડનો સીધો, અનિયંત્રિત ઉપયોગ કરી શકવું જોઈએ નહીં. હાર્નેસ નક્કી કરે છે કે મોડલને શેને સ્પર્શ કરવાની મંજૂરી છે અને અમલીકરણ પહેલાં વિનંતીઓ કેવી રીતે વેલિડેટ કરવામાં આવે છે.
એક સાદું ઉદાહરણ લો: એક સપોર્ટ એજન્ટ જે ઓર્ડર સ્ટેટસ જોઈ શકે છે અને રિફંડ આપી શકે છે. મોડલ કુદરતી ભાષામાં ક્રિયાઓ સૂચવે છે. હાર્નેસ તે સૂચનોને સ્ટ્રક્ચર્ડ API કોલ્સમાં મેપ કરે છે, યુઝર પરમિશન તપાસે છે, ઓર્ડર ID વિનંતી કરનાર વપરાશકર્તાના એકાઉન્ટમાં છે કે નહીં તે વેલિડેટ કરે છે, રેટ લિમિટ્સ લાગુ કરે છે, અને ચોક્કસ મર્યાદાથી વધુ રિફંડ માટે સ્પષ્ટ માનવ પુષ્ટિ (human confirmation) જરૂરી બનાવે છે. મોડલ પ્રસ્તાવ મૂકે છે. હાર્નેસ પરવાનગી આપે છે. "'મોડલ હવે સ્માર્ટ છે' એમ કહીને આમાંથી કોઈપણ લેયર દૂર કરવું એ એક મોંઘી જવાબદારી (liability) ઊભી કરવા જેવું છે."
તે જ બાબત કન્ટેન્ટ સેફ્ટીને પણ લાગુ પડે છે. બેઝ મોડલ્સ હાનિકારક, પક્ષપાતી અથવા બ્રાન્ડને અનુરૂપ ન હોય તેવા આઉટપુટ આપી શકે છે. હાર્નેસ આઉટપુટ ક્લાસિફાયર્સ, બદલાયેલા પ્રોમ્પ્ટ્સ સાથે રિટ્રાય પોલિસી અને ઓડિટ ટ્રેલ માટે લોગિંગ લાગુ કરે છે. ફાઉન્ડેશન મોડલ પ્રોવાઈડર આ સમસ્યાને સંપૂર્ણ રીતે ઉકેલે તેની રાહ જોવી એ કોઈ વ્યૂહરચના નથી; તે તમારી પ્રતિષ્ઠા સાથેનો જુગાર છે.
પ્રોડક્શન હાર્નેસનું બંધારણ
જો તમે લાંબા ગાળા માટે કંઈક બનાવી રહ્યા હોવ, તો તમારા હાર્નેસને અન્ય કોઈપણ બેકએન્ડ સિસ્ટમની જેમ જ કાળજીપૂર્વક આર્કિટેક્ટ કરવાની જરૂર છે. અહીં તે ઘટકો છે જે રમકડાં અને સાધનો વચ્ચે તફાવત કરે છે.
ઇવેલ્યુએશન અને રિગ્રેશન ટેસ્ટિંગ. તમારે વાસ્તવિક યુઝર ક્વેરીઝ અને અપેક્ષિત વર્તણૂકનો એક સેટ જોઈએ જે દરેક ડિપ્લોયમેન્ટ પહેલા આપમેળે ચાલે. તમારા પ્રોમ્પ્ટ ટેમ્પલેટમાં ફેરફાર કરો અથવા મોડલ્સ બદલો, અને તમારે મિનિટોમાં જ દેખાવું જોઈએ કે ચોકસાઈ સુધરી છે કે તમે કોઈ મહત્વપૂર્ણ વર્કફ્લો તોડી નાખ્યો છે.
અવલોકનક્ષમતા અને ટ્રેસિંગ (Observability and tracing). LLM કોલ્સ અનિશ્ચિત (non-deterministic) અને ખર્ચાળ હોય છે. તમારે રિટ્રીવલ (retrieval), પ્રોમ્પ્ટ કન્સ્ટ્રક્શન, મોડેલ ઇન્ફરન્સ અને પોસ્ટ-પ્રોસેસિંગ દ્વારા દરેક વિનંતીને ટ્રેસ કરવાની જરૂર છે. જ્યારે કોઈ વપરાશકર્તા ખરાબ પરિણામની જાણ કરે છે, ત્યારે તમે તે પરિણામ આપનાર ચોક્કસ સંદર્ભ (context) અને પ્રોમ્પ્ટને ફરીથી બનાવી શકવા સક્ષમ હોવા જોઈએ.
સંદર્ભ એન્જિનિયરિંગ (Context engineering). મોટાભાગની પ્રોડક્શન નિષ્ફળતાઓ ખરાબ સંદર્ભને કારણે હોય છે, મોડેલની મૂર્ખતાને કારણે નહીં. તમારું હાર્નેસ (harness) ચંકિંગ વ્યૂહરચનાઓ, રિટ્રીવલ રેન્કિંગ, ટોકન બજેટ અને રી-રેન્કિંગ લોજિકનું સંચાલન કરે છે. ઉત્તમ રિટ્રીવ્ડ કોન્ટેક્સ્ટ ધરાવતું એક સામાન્ય મોડેલ, નબળા કોન્ટેક્સ્ટ ધરાવતા ફ્રન્ટિયર મોડેલને લગભગ દરેક વખતે હરાવશે.
ટૂલનો ઉપયોગ અને ગાર્ડરેલ્સ (Tool use and guardrails). મોડેલ જે કોઈપણ ફંક્શનને ઇનવોક (invoke) કરી શકે છે, તેણે સ્કીમા વેલિડેશન, પરમિશન ચેક્સ અને સેનિટાઈઝેશનમાંથી પસાર થવું આવશ્યક છે. હાર્નેસ દ્વારા પાર્સિંગ ભૂલોને કુશળતાપૂર્વક સંભાળવી જોઈએ. જો મોડેલ કોઈ પેરામીટરનું હેલ્યુસિનેશન (hallucinates) કરે, તો હાર્નેસ તેને એક્ઝિક્યુટ કરવાને બદલે કોલને નકારી દે છે.
ખર્ચ અને લેટન્સી નિયંત્રણો (Cost and latency controls). દરેક ક્વેરી માટે સૌથી મોટા મોડેલની જરૂર નથી. હાર્નેસમાં રહેલું એક રાઉટિંગ લેયર આવતી વિનંતીઓને વર્ગીકૃત કરી શકે છે અને જટિલ કાર્યો માટે મોંઘા રીઝનિંગને અનામત રાખતા, સરળ પ્રશ્નોને નાના અને ઝડપી મોડેલોને મોકલી શકે છે. સામાન્ય પ્રતિસાદોનું કેશિંગ (caching) બિનજરૂરી ઇન્ફરન્સને અટકાવે છે.
ફીડબેક લૂપ્સ (Feedback loops). હાર્નેસમાં થમ્બ્સ-અપ, થમ્બ્સ-ડાઉન, સુધારાઓ અને ફોલો-અપ પ્રશ્નો જેવા અસ્પષ્ટ સંકેતોને કેપ્ચર કરવા જોઈએ. આ ડેટા પ્રોમ્પ્ટ રિફાઇનમેન્ટ, ફાઇન-ટ્યુનિંગ અથવા ઇવેલ્યુએશન સેટના વિસ્તરણમાં ઉપયોગી થાય છે. મોડેલ પ્રોડક્શનમાંથી આપમેળે શીખતું નથી; હાર્નેસને આ પાઠો એકત્રિત કરવા પડે છે.
મોડેલ્સ એ કોમોડિટી છે. હાર્નેસ એ મોટ્સ (Moats) છે.
ફાઉન્ડેશન મોડેલ લેયર ઝડપથી સંકોચાઈ રહ્યું છે. કિંમતો ઘટી રહી છે, ઓપન વેટ્સ ક્ષમતાના તફાવતને ઘટાડી રહ્યા છે, અને દરેક ક્વાર્ટરમાં પ્રોવાઇડર્સ વચ્ચે સ્વિચિંગ ખર્ચ ઓછો થઈ રહ્યો છે. બે વર્ષમાં, તમે પસંદ કરેલું ચોક્કસ મોડેલ સંભવતઃ ત્રણ સસ્તા વિકલ્પો સાથે બદલી શકાય તેવું હશે. જે એન્જિનિયરિંગ રોકાણ ટકી રહેશે તે એ ઇન્ફ્રાસ્ટ્રક્ચર છે જે તમે તેની આસપાસ બનાવેલું છે.
જે કંપનીઓ આ સમજે છે તેઓ તેમના સૌથી દુર્લભ સંસાધન—તેજસ્વી એન્જિનિયરિંગ સમય—ને સિસ્ટમ્સ ઇન્ટિગ્રેશન લેયર પર કેન્દ્રિત કરે છે. તેઓ તેમના ડોમેન સાથે જોડાયેલા પ્રોપ્રાઇટરી ઇવેલ્યુએશન ડેટાસેટ્સ બનાવે છે. તેઓ એવા રિટ્રીવલ પાઇપલાઇન્સ બનાવે છે જે વર્ષોના સંચિત સંસ્થાકીય જ્ઞાનને પ્રતિબિંબિત કરે છે. તેઓ એવા ઇન્ટરેક્શન પેટર્ન ડિઝાઇન કરે છે જે જ્યાં નિર્ણય લેવો જરૂરી હોય ત્યાં માનવીઓને લૂપમાં રાખે છે. તે સુરક્ષિત (defensible) છે. વધુ સારું API એન્ડપોઇન્ટ નથી.
આનો અર્થ એ પણ છે કે તમારો રોડમેપ બીજી કંપનીના રિલીઝ સાયકલનો બંધક ન હોવો જોઈએ. એક મજબૂત હાર્નેસ તમને ન્યૂનતમ મુશ્કેલી સાથે ફાઉન્ડેશન મોડેલ્સ બદલવાની સુવિધા આપે છે. જ્યારે નવું વર્ઝન આવે છે, ત્યારે તમે તમારી ઇવેલ્યુએશન સૂટ ચલાવો છો, રિગ્રેશન્સ તપાસો છો, અને જો આંકડા સુધરે તો બદલી નાખો છો. હાર્નેસ વગર, તમે માત્ર એ પ્રાર્થના કરવામાં અટવાયેલા રહેશો કે લેટેસ્ટ મોડેલ ચેન્જલોગ તમારી જરૂરિયાતો સાથે મેળ ખાય.
વાસ્તવિક નિષ્કર્ષ (The Real Takeaway)
મોડેલની પસંદગીને પ્રાથમિક વ્યૂહાત્મક નિર્ણય તરીકે લેવાનું બંધ કરો. તે પ્રાપ્તિ (procurement) નો પ્રશ્ન છે. વ્યૂહાત્મક કાર્ય એ મશીનરી બનાવવાનું છે જે મોડેલના આઉટપુટને સુરક્ષિત રીતે, સતત અને અવલોકનક્ષમ રીતે બિઝનેસ પરિણામોમાં ફેરવે છે. મોડેલ ખરીદો, પરંતુ હાર્નેસ બનાવો. AI ડિપ્લોયમેન્ટના આગામી તબક્કામાં જે ટીમો જીતશે તે એવી હશે જેઓ સમજી શકશે કે સરેરાશ મોડેલ પર બનેલી વિશ્વસનીય સિસ્ટમ, તેજસ્વી મોડેલ પર બનેલી અનિયંત્રિત સિસ્ટમને દર વખતે હરાવે છે.