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

અત્યારે, દરેક વ્યક્તિ દરેક વસ્તુને એજન્ટ (agent) કહે છે. એક સ્ક્રિપ્ટ જે કોઈ શરત પૂરી ન થાય ત્યાં સુધી લૂપમાં ચાલે છે, તે અચાનક એજન્ટ બની જાય છે. એક ચેટબોટ જે મેમરીમાં છેલ્લા ત્રણ મેસેજ સ્ટોર કરે છે, તે પણ એજન્ટ છે. આ અસ્પષ્ટ શબ્દભંડોળ એન્જિનિયરિંગમાં વાસ્તવિક નુકસાન પહોંચાડે છે. ટીમો પાંચ-સ્ટેપના વર્કફ્લોને ઓટોમેટ કરવા માટે ભારે એજન્ટ ફ્રેમવર્કનો ઉપયોગ કરે છે, જેનું કામ એક સાધારણ cron job પણ કરી શકતું હોય. સાથે જ, તેઓ વાસ્તવિક જટિલતામાં ઓછું રોકાણ કરે છે કારણ કે આ લેબલથી એવું લાગે છે કે લાર્જ લેંગ્વેજ મોડલ જાદુઈ રીતે તમામ એજ કેસીસ (edge cases) ઉકેલી નાખશે. તે આવું નહીં કરે.

એજન્ટ ખરેખર શું છે

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

તમે જે કંઈ પણ બનાવી રહ્યા છો તેને ચકાસવા માટે આ ત્રણ નિયમોનો ઉપયોગ કરો:

  • જો માણસે તેને દરેક સ્ટેપ જણાવવું પડે, તો તે માત્ર એક ચેટ ઇન્ટરફેસ છે. તમે ડ્રાઇવિંગ કરી રહ્યા છો. સિસ્ટમ માત્ર એક ખૂબ જ નમ્ર સ્ટીયરિંગ વ્હીલ છે.
  • જો તે નિષ્ફળ ટૂલ કોલમાંથી રિકવર કરી શકે, તો તમે સાચા માર્ગ પર છો. સર્ચ API ટાઇમઆઉટ થાય અથવા 500 એરર આપે તો કામ અટકી ન જવું જોઈએ. સિસ્ટમે ફરી પ્રયાસ (retry) કરવો જોઈએ, થોડી રાહ જોવી જોઈએ, ફોલબેક સોર્સ પર સ્વિચ કરવું જોઈએ અથવા મદદ માંગવી જોઈએ.
  • જો તે લક્ષ્યને પેટા-કાર્યોમાં વિભાજિત કરે અને તેમને સોંપે, તો તે સાચો એજન્ટ છે. તેને "Q3 કમ્પ્લાયન્સ રિપોર્ટ તૈયાર કરો" જેવી કમાન્ડ આપો, અને તે ડેટા સોર્સ ઓળખશે, ડેટા એક્સટ્રેક્શનનું શેડ્યૂલ બનાવશે, કાચા આંકડાઓને કેલ્ક્યુલેશન મોડ્યુલને આપશે, રિવ્યુ માટે ડ્રાફ્ટ મોકલશે અને ક્યારે અટકવું તે જાણશે.

જો તમારી સિસ્ટમ આ વસ્તુઓ નથી કરતી, તો તમારી પાસે એજન્ટની સમસ્યા નથી. તમારી પાસે સ્ક્રિપ્ટિંગની સમસ્યા અથવા વર્કફ્લોની સમસ્યા છે. આ વાત વહેલી સ્વીકારી લેવાથી તમે ફ્રેમવર્કના વધારાના બોજથી બચી શકો છો.

વિજેતા ટીમો ખરેખર શેને પ્રાથમિકતા આપે છે

જે ટીમો વિશ્વસનીય સિસ્ટમ્સ બનાવે છે તેઓ બેન્ચમાર્ક પર થોડા પોઈન્ટ્સ મેળવવા માટે સતત લેટેસ્ટ મોડલ રિલીઝ બદલવામાં પોતાનો દિવસ નથી વિતાવતા. તેઓ ત્રણ કંટાળાજનક પરંતુ ઉચ્ચ પ્રભાવ ધરાવતા ક્ષેત્રો પર ધ્યાન કેન્દ્રિત કરે છે.

ટૂલ ડિઝાઇન (Tool design). તમારો એજન્ટ એટલો જ સારો છે જેટલા સારા ટૂલ્સ તમે તેને આપો છો. જો સર્ચ ફંક્શન અસંગત ફીલ્ડ નામો સાથે કાચું, નેસ્ટેડ JSON રિટર્ન કરે છે, તો મોડલ કન્ટેન્ટ વિશે વિચારવાને બદલે સ્ટ્રક્ચર પાર્સ કરવામાં કિંમતી કોન્ટેક્સ્ટ વિન્ડોનો બગાડ કરે છે. જો ટૂલના વર્ણનો અસ્પષ્ટ હોય, તો મોડલ ખોટા આર્ગ્યુમેન્ટ્સ બનાવે છે (hallucinates). ટૂલ ઇન્ટરફેસને એક એવા ખૂબ જ સીધા (literal) જુનિયર ડેવલપર માટે API ની જેમ ગણો જેને ક્લીન ઇનપુટ્સ, અનુમાનિત આઉટપુટ્સ અને સ્પષ્ટ એરર સ્ટેટ્સની જરૂર હોય છે.

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

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

એવા આર્કિટેક્ચર પેટર્ન જે ફ્રેમવર્ક કરતાં વધુ સમય ટકે છે

LangChain, CrewAI અને હવે પછીના છ મહિનામાં આવનાર કોઈપણ હોટ ફ્રેમવર્ક એ માત્ર સ્કેફોલ્ડિંગ (માળખું) છે. આર્કિટેક્ચર એ ઇમારત છે. જો તમારી ડિઝાઇન નબળી હશે, તો કોઈ ફ્રેમવર્ક તેને બચાવી શકશે નહીં. એવા પેટર્ન્સ પર ટકી રહો જે લાંબા સમય સુધી સાબિત થયા છે:

  • પહેલા યોજના બનાવો, પછી અમલ કરો. મોડેલને એકસાથે વિચારવા અને કાર્ય કરવા ન દો. પહેલા, એક યોજના બનાવો. પછી પગલાંઓ ચલાવો. જ્યારે કંઈક ખોટું થાય, ત્યારે તમે અમલીકરણથી સ્વતંત્ર રીતે યોજનાનું નિરીક્ષણ કરી શકો છો. તમે ઇન્ટરલીવ્ડ (interleaved) ટૂલ કોલ્સ અને સ્ટ્રીમ-ઓફ-કોન્શિયસનેસ રીઝનિંગના ગૂંચવણભર્યા જાળાને ઉકેલવામાં ઘણો ઓછો સમય વિતાવશો.
  • રીટ્રીવલ (retrieval) ને રીઝનિંગ (reasoning) થી અલગ કરો. સંદર્ભ મેળવવો એ I/O નું કામ છે. સંદર્ભનો ઉપયોગ કરવો એ રીઝનિંગનું કામ છે. આ બંનેને મિશ્રિત કરવાનો અર્થ એ છે કે તમારું રીટ્રીવર મોડેલની ટોકન મર્યાદાઓ દ્વારા મર્યાદિત છે, અને તમારું મોડેલ કાચા રીટ્રીવલ નોઈઝ (noise) થી પ્રદૂષિત થાય છે. રીટ્રીવલ લેયરને આક્રમક રીતે ડેટા મેળવવા દો. રીઝનિંગ લેયરને તે જે મેળવ્યું છે તેનું શંકાસ્પદ રીતે મૂલ્યાંકન કરવા દો.
  • સ્પષ્ટ હેન્ડઓફ્સ (handoffs) નો ઉપયોગ કરો. જો બહુવિધ એજન્ટ્સ કોઈ કાર્યમાં સામેલ હોય, તો કામ સોંપવાની પ્રક્રિયાને વ્યવસ્થિત બનાવો. સ્પષ્ટ આઉટપુટ સ્કીમા, માલિકીની સીમાઓ અને હેન્ડઓફ લોગ્સ વ્યાખ્યાયિત કરો. એજન્ટો વચ્ચેની અસ્પષ્ટ અનૌપચારિક ચેટથી કાર્યો બાકી રહી જવા, સર્ક્યુલર લૂપ્સ અથવા ડુપ્લીકેટ કામ થઈ શકે છે. એજન્ટ-ટુ-એજન્ટ વાતચીતને ગ્રુપ ચેટ તરીકે નહીં, પરંતુ સારી રીતે વ્યાખ્યાયિત API કોન્ટ્રાક્ટ તરીકે ગણો.

તમારું RAG કચરો (garbage) કેમ રિટર્ન કરે છે તેનું સાચું કારણ

જો તમારું retrieval-augmented generation પાઇપલાઇન નકામા પરિણામો આપતી જણાતી હોય, તો એમ્બેડિંગ મોડેલને ટ્યુન કરવાનું બંધ કરો અને તમારી ચંકિંગ (chunking) વ્યૂહરચના જુઓ. RAG સિસ્ટમ્સમાં આ સૌથી વધુ અવગણવામાં આવતો નિષ્ફળતાનો મુદ્દો છે.

જ્યારે તમે દસ્તાવેજોને કડક નિશ્ચિત-કદના ચંક્સમાં વિભાજિત કરો છો, ત્યારે તમે ઘણીવાર વિચારોને અસંબંધિત બનાવી દો છો. એક ફકરો જે “જોકે, આ અભિગમ નિયમનકારી ફેરફારોને ધ્યાનમાં લેવામાં નિષ્ફળ રહ્યો” થી શરૂ થાય છે, તે અગાઉના ફકરા વગર કોઈ અર્થ ધરાવતો નથી જેણે તે અભિગમનું નામ આપ્યું હોય. જો તમે તે અલગ પડેલા ટુકડાને મોડેલને આપશો, તો મોડેલ તેને જરૂરી હોય તેવો સંદર્ભ જાતે જ બનાવી લેશે. તે રીટ્રીવલ નથી; તે હેલ્યુસિનેશન ફેક્ટરી (hallucination factory) છે.

આ સુધારાઓ અજમાવો:

  • ઓવરલેપિંગ વિન્ડોઝ (Overlapping windows). નજીકના ચંક્સને સીમાઓ પર એક કે બે વાક્યો વહેંચવા દો જેથી વિચારો અધવચ્ચે અટકી ન જાય.
  • સેમેન્ટિક ચંકિંગ (Semantic chunking). કેરેક્ટર કાઉન્ટને બદલે કુદરતી સીમાઓ—ફકરાના અંત, સેક્શન હેડર્સ અથવા વિષયના ફેરફાર—પર વિભાજિત કરો.
  • પેરેન્ટ-ડોક્યુમેન્ટ રીટ્રીવલ (Parent-document retrieval). સેમેન્ટિક મેચિંગ માટે નાના, ચોક્કસ ચંક્સ મેળવો, પરંતુ લેંગ્વેજ મોડેલને સંપૂર્ણ પેરેન્ટ સેક્શન અથવા દસ્તાવેજ આપો જેથી જ્યારે તે જનરેટ કરે ત્યારે તેની પાસે આસપાસનો સંદર્ભ હોય.
  • કાચા ટેક્સ્ટને બદલે સ્ટ્રક્ચર્ડ ડેટા સ્ટોર કરો. ટેબ્યુલર ડેટા, કી-વેલ્યુ જોડી અને સંબંધો ઘણીવાર ગદ્ય (prose) તરીકે નબળા રીતે એમ્બેડ થાય છે. જો તમારી સોર્સ મટીરીયલ સ્ટ્રક્ચર્ડ હોય, તો તેને ગ્રાફ ડેટાબેઝ અથવા રિલેશનલ સ્ટોરમાં સ્ટ્રક્ચર્ડ રાખો અને એજન્ટને એમ્બેડેડ ટેક્સ્ટ ફ્રેગમેન્ટ્સમાંથી અનુમાન લગાવવાને બદલે તેને સ્પષ્ટ રીતે ક્વેરી કરવા દો.

એવા સિસ્ટમ્સ બનાવો જેના પર તમે વિશ્વાસ કરી શકો

બેન્ચમાર્ક પાછળ દોડવાનું બંધ કરો. લીડરબોર્ડ સ્કોર એ લેબની સ્થિતિ છે. પ્રોડક્શન અસ્તવ્યસ્ત, વિરોધી અને અસિંક્રોનસ (async) હોય છે. જે મહત્વનું છે તે એ છે કે જ્યારે તમે સૂતા હોવ, જ્યારે અપસ્ટ્રીમ API અસ્થિર હોય અને જ્યારે વપરાશકર્તા કંઈક એવું પૂછે જે ટ્રેનિંગ ડેટામાં ન હોય, ત્યારે તમારી સિસ્ટમ યોગ્ય રીતે વર્તે છે કે નહીં.

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

સ્ત્રોત: The Overlooked Reason Your RAG Pipeline Keeps Returning Garbage

લર્નિંગ કોમ્યુનિટીમાં જોડાઓ: GyaanSetu AI on Telegram