LLMs તમારા કોડમાં પ્રવેશતા નથી – તેઓ તમને વિનંતી (request) આપે છે, અને તમે ફંક્શન ચલાવો છો. આ સરળ હકીકત એ માન્યતાને બદલી નાખે છે કે "મોડેલ જાદુઈ રીતે મારી Python રૂટિનને કોલ કરે છે" અને ડેવલપર્સને ડિબગિંગ અને સુરક્ષા વિશે ફરીથી વિચારવા માટે મજબૂર કરે છે.

ડિસ્પેચ લૂપ (dispatch loop), સ્ટેપ બાય સ્ટેપ

જ્યારે લેંગ્વેજ મોડેલ (LLM) ને કોઈ ટૂલની જરૂર હોય, ત્યારે તે એક નિશ્ચિત (deterministic) ક્રમ અનુસરે છે:

  1. Planning (આયોજન) – મોડેલ નક્કી કરે છે કે કોઈ ક્રિયા જરૂરી છે (દા.ત., "પેમેન્ટ રિફંડ કરવું").
  2. Generating a request (વિનંતી બનાવવી) – તે સ્ટ્રક્ચર્ડ ટેક્સ્ટ—સામાન્ય રીતે JSON—આઉટપુટ કરે છે જે ટૂલનું નામ આપે છે અને આર્ગ્યુમેન્ટ્સ (arguments) પૂરા પાડે છે.
  3. Parsing (પાર્સિંગ) – તમારું એપ અથવા સપોર્ટિંગ ફ્રેમવર્ક તે ટેક્સ્ટ વાંચે છે.
  4. Matching (મેચિંગ) – ફ્રેમવર્ક તમે એક્સપોઝ કરેલા વાસ્તવિક ફંક્શન્સના રજિસ્ટ્રીમાં નામ શોધે છે.
  5. Validating (વેલિડેશન) – તે તપાસે છે કે આર્ગ્યુમેન્ટ્સ ફંક્શનના સ્કીમા (schema) સાથે મેળ ખાય છે અને કોલર (caller) અધિકૃત છે કે નહીં.
  6. Executing (એક્ઝિક્યુશન) – મેચ થયેલું ફંક્શન તમારા એન્વાયરમેન્ટમાં ચાલે છે અને કામ પૂરું કરે છે.
  7. Returning (પરત કરવું) – પરિણામને પેકેજ કરવામાં આવે છે અને વધુ તર્ક (reasoning) માટે મોડેલને પાછું મોકલવામાં આવે છે.

LLM ને પ્લાનર તરીકે, ફ્રેમવર્કને ડિસ્પેચર તરીકે અને ફંક્શનને એવા વર્કર તરીકે વિચારો જે ખરેખર ડેટા અથવા પૈસાનું હસ્તાંતરણ કરે છે.

"જાદુઈ" માન્યતા શા માટે ટકી રહે છે

મોટાભાગના ડેવલપર્સ મોડેલ આઉટપુટની એક એવી લાઇન જુએ છે જે ફંક્શન કોલ જેવી લાગે છે અને માની લે છે કે મોડેલે પોતે જ ઓપરેશન કર્યું છે. પ્રોવાઇડર ડોક્યુમેન્ટ્સમાં "tool calling" શબ્દ એવું લાગે છે કે જાણે મોડેલ સીધું જ કોડ ઇનવોક (invoke) કરી રહ્યું હોય.

વાસ્તવિકતામાં, મોડેલ ફક્ત એવી ટેક્સ્ટ ઉત્પન્ન કરે છે જે કોલનું વર્ણન કરે છે. તમારો પ્રોસેસ મુખ્ય કામ કરે છે—લુકઅપ, ટાઇપ ચેકિંગ, પરમિશન એન્ફોર્સમેન્ટ અને એરર હેન્ડલિંગ.

ફ્રેમવર્ક જે અંદરની જટિલતાઓને છુપાવે છે (Frameworks that hide the plumbing)

PydanticAI અને LangChain જેવી લાઇબ્રેરીઓ લૂપને એબ્સ્ટ્રેક્ટ (abstract) કરે છે જેથી તમે બિઝનેસ લોજિક પર ધ્યાન કેન્દ્રિત કરી શકો. તેઓ આપમેળે:

  • Validate arguments – સ્કીમા (દા.ત., Pydantic મોડેલ) સામે આર્ગ્યુમેન્ટ્સનું વેલિડેશન કરે છે.
  • Enforce permissions – પરમિશન લાગુ કરે છે, જે સુનિશ્ચિત કરે છે કે યુઝર ટૂલ ટ્રિગર કરી શકે છે.
  • Retry on failure – નિષ્ફળતા પર ફરી પ્રયાસ કરે છે, જ્યારે ટૂલ એરર રિટર્ન કરે ત્યારે મોડેલ પાસે પાછા જાય છે.
  • Guard against runaway loops – અનિયંત્રિત લૂપ્સ સામે રક્ષણ આપે છે, સતત થતા ટૂલ કોલ્સ પર મર્યાદા મૂકે છે.
  • Maintain conversation state – વાતચીતની સ્થિતિ જાળવી રાખે છે, ટૂલના પરિણામોને સંવાદમાં જોડે છે.

આ મદદગારો હોવા છતાં, પેટર્ન સમાન રહે છે: મોડેલ ક્યારેય કોડ એક્ઝિક્યુટ કરતું નથી.

પ્રોવાઇડર્સ તરફથી નેટિવ ટૂલ-કોલિંગ સપોર્ટ (Native tool-calling support)

કેટલાક પ્રોવાઇડર્સ "નેટિવ" ટૂલ-કોલિંગ ઇન્ટરફેસ આપે છે જે ટૂલ ડેફિનેશન અને રિક્વેસ્ટ ફોર્મેટને સ્ટાન્ડર્ડાઇઝ કરે છે. તે ઇન્ટિગ્રેશનને સરળ બનાવે છે પરંતુ ડિસ્પેચ સ્ટેપને દૂર કરતું નથી. તમે હજુ પણ તે કોડ લખો છો (અથવા ઇમ્પોર્ટ કરો છો) જે ખરેખર વિનંતી કરેલ ઓપરેશન ચલાવે છે.

જ્યારે તમે સમસ્યાનું નામ બદલો છો ત્યારે ડિબગિંગ સરળ બને છે

"ગૂંચવાયેલા એજન્ટ" ને દોષ આપવાને બદલે, એમ કહો કે સમસ્યા એ છે કે "મોડેલના પ્રતિસાદમાં કોઈ ટૂલ કોલ્સ નહોતા." આ તફાવત મહત્વનો છે:

  • No tool call – મોડેલે સીધો જવાબ આપ્યો અથવા યોગ્ય રીતે ફોર્મેટ કરેલી વિનંતી બનાવવામાં નિષ્ફળ ગયું.
  • Malformed request – JSON સિન્ટેક્ટિકલી ખોટું છે અથવા જરૂરી ફિલ્ડ્સ ખૂટે છે, તેથી ડિસ્પેચર તેને નકારી દે છે.
  • Validation failure – આર્ગ્યુમેન્ટ્સ સ્કીમા સાથે મેળ ખાતા નથી, જેનાથી એક્ઝિક્યુશન પહેલાં એરર આવે છે.

નિષ્ફળતાઓને વર્ગીકૃત કરવાથી તમે લૂપના દરેક તબક્કાને લોગ કરી શકો છો અને વસ્તુઓ ક્યાં ખોટી થઈ તે ચોક્કસ રીતે જાણી શકો છો.

વિશ્વસનીય પાઇપલાઇન માટે વ્યવહારુ ટિપ્સ

  • મોડેલ આઉટપુટને અનટ્રસ્ટેડ ઇનપુટ તરીકે ગણો. કોઈપણ સાઇડ-ઇફેક્ટ કરતો કોડ ઇનવોક કરતા પહેલા દરેક વિનંતીને નિશ્ચિત (deterministic) વેલિડેશન દ્વારા પસાર કરો.
  • રો (raw) રિક્વેસ્ટ લોગ કરો અને દરેક વેલિડેશન સ્ટેપનું પરિણામ લોગ કરો. જ્યારે કંઈક ખોટું થાય ત્યારે આ એક રિપ્લે કરી શકાય તેવો ટ્રેલ બનાવે છે.
  • સતત થતા ટૂલ કોલ્સ પર સ્પષ્ટ મર્યાદાઓ સેટ કરો; અનિયંત્રિત લૂપ સંસાધનો (resources) ખતમ કરી શકે છે અથવા રેટ લિમિટ સુધી પહોંચી શકે છે.
  • દરેક ફંક્શનને try/except બ્લોકમાં રેપ કરો જે મોડેલ સમજી શકે તેવું સ્ટ્રક્ચર્ડ એરર ઓબ્જેક્ટ રિટર્ન કરે, જે ફરીથી પ્રયાસ કરવા અથવા ગ્રેસફુલ ફોલબેક માટે પ્રોમ્પ્ટ કરે.
  • પરમિશન ચેક્સને બિઝનેસ લોજિકથી અલગ કરો. ફંક્શન ચાલતા પહેલા કોલરના અધિકારો ચકાસો, ખાસ કરીને "delete user" જેવી વિશિષ્ટ ક્રિયાઓ માટે.
  • સ્કીમા-ડ્રિવન ડેફિનેશનનો ઉપયોગ કરો (દા.ત., Pydantic મોડેલ્સ) જેથી ફ્રેમવર્ક એ JSON સ્કીમા આપમેળે જનરેટ કરી શકે જે મોડેલે અનુસરવું જોઈએ.

આગળ શું જોવું

જેમ જેમ પ્રોવાઇડર્સ નેટિવ ટૂલ-કોલિંગ APIs ને વધુ સુધારે છે, તેમ રિક્વેસ્ટ ફોર્મેટની આસપાસ વધુ સચોટ કરાર (tighter contracts) અને વધુ વિગતવાર એરર કોડ્સની અપેક્ષા રાખવી. આ ફેરફારો વેલિડેશનને સરળ બનાવશે અને ડેવલપર્સને વધુ કડક સુરક્ષા કવચ બનાવવામાં મદદ કરશે. લાઇબ્રેરી અપડેટ્સ પર નજર રાખો—ઘણી લાઇબ્રેરીઓ નવા પ્રોવાઇડર ફીચર્સ માટે ઇન-બિલ્ટ સપોર્ટ ઉમેરી રહી છે.

મુખ્ય વાત (Takeaway)

LLM એ એક અત્યાધુનિક ટેક્સ્ટ જનરેટર છે, એક્ઝિક્યુટર નથી. તમારો કોડ એ ક્રિયાઓ કરનારી એકમાત્ર સત્તા છે, અને તમે બનાવેલ (અથવા ઇમ્પોર્ટ કરેલ) ડિસ્પેચર એ ગેટકીપર છે જે તે ક્રિયાઓને પ્રમાણિત કરે છે, અધિકૃત કરે છે અને ચલાવે છે. વર્કફ્લોને ફરીથી વ્યાખ્યાયિત કરવાથી "મેજિક" (જાદુ) નો ભ્રમ દૂર થાય છે, ડીબગિંગ વધુ સચોટ બને છે, અને દરેક પ્રોડક્શન સિસ્ટમને જરૂરી સુરક્ષા શિસ્તનો અમલ થાય છે.